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ABSTRACT 



The Fleet Area Control and Surveillance Facility FAC5- 
FAC located at North Island, San Diego, currently performs 
its data collection, storage and processing functions 
manually. Expected expansion of the scope of operations at 
FACSFAC will overwhelm the present system. 

This thesis develops an ORACLE-based relational data- 
base system for use by FACSFAC. The system consists of two 
applications. In the scheduling application, inputs from 
various sources are compiled, allowing both a powerful query 
capability and the production of a weekly schedule of ac- 
tivities for the facilities and personnel assigned to FACS- 
FAC. The exercise results application provides an automated 
method of gathering and querying pertinent tactical employ- 
ment and range utilization data for required weekly, monthly 
and quarterly reports. 

The prototype system greatly facilitates the storage, 
query and reporting functions of the organization and pro- 
motes increased efficiency in day-to-day operations. 
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I . INTRODUCTION 



A. BACKGROUND 

The Fleet Area Control and Surveillance Facility (FACS- 
FAC) is located aboard Naval Air Station North Island, San 
Diego, California. It is a command of the U.S. Navy whose 
current mission is to provide specialized an t isubmar ine 
warfare (ASUJ) and electronic warfare (EUJ) training support 
at the Southern California Offshore Range (SCORE) to the 
operational forces of the Commander in Chief, Pacific Fleet 
( C I NCPACFLT ) . In executing its assigned mission, FACSFAC 
schedules and operates the range, provides for simulated 
and/or actual submarine targets, monitors the performance of 
units exercising on the range, and collects and analyzes 
tactical data from fleet units conducting training on the 
range. When weapons and/or simulated targets are involved, 
FACSFAC provides for the retrieval of those assets at the 
completion of the exercise. Additionally, FACSFAC is tasked 
with the safe and orderly conduct of all exercises under- 
taken on the various SCORE ranges. 

The Southern California ASUJ Range (SOAR) provides “an 
instrumented, three-dimensional, in-air and underwater 
tracking range" [Ref. i : pg . i] for use by west coast air, 
surface and submarine commands. Presently, the 112 square 
mile range is capable of simultaneously tracking up to eight 
surface and air platforms and four in-water vehicles. 
Planned upgrades to the range include expansion to 600 
square miles in area, with improved track resolution and 
tracking capability. 

The EUJ range currently provides training to west coast 
surface ships through the use of a noise jammer simulation 
subsystem and a temporary radar signal simulator (RSS-19) 
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[Ref. 1 : pg . 1]. Training opportunities for the west coast 
air communities are also being explored. Future expansion of 
the EW range capabilities will include threat radar simula- 
tion and participant response monitoring. These upgrades 
should benefit air participants and attract additional 
surface units. 

As SCORE continues to evolve, additional ranges and 
equipment will become available to support training exer- 
cises in ASW , EW, Weapons Impact Scoring, No-Drop Laser 
Scoring and Naval Gunfire Support (NGFS). A future integra- 
ted Range Operations Center (ROC) will accommodate a wide 
range of exercise scenarios involving multiple warfare 
areas . 



B. STATEMENT OF 

The proposed 


PROBLEM 

expansion 


of range size and 


data col 


tion capabilities 


wi 1 1 


o ve 


rwhelm the manual da 


ta hand 


techniques of the 


current 


F ACSF AC management 


inf orma 


system. Not only 


will 


the 


scheduling process 


become 



more 

complicated with the development of additional ranges and 
the increased utilization of those ranges, but the quantity 
of tactical data collected during the exercises is expected 
to double. Clearly, the present manual system cannot be ex- 
pected to cope with this growth. Lack of an automated data- 
base causes an inordinate amount of time to be spent manual- 
ly searching files for data required for the various re- 
ports. Optional data manipulation functions are not being 
performed by the Program Engineers due to the tedium as- 
sociated with the file searches. These optional functions, 
consisting mainly of tactical employment comparisons, could 
be of significant use to the training departments of the 
client commands. 
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C . SCOPE 

The implementation of an automated database to gather 
and store schedule and exercise results data and to create 
an exercise schedule is just one facet of the integrated 
management information system envisioned by FACSFAC. The ul- 
timate goal is the creation of the Southern California Range 
Asset Management Network (SCRAMNET), comprised of worksta- 
tions and shared peripherals to create an integrated infor- 
mation resources system for the SCORE. The SCRAMNET will 
consist of three major components: database applications, 
the hardware/operating system, and text/graphics. 

The database applications component, called the South- 
ern California Range Asset Management Database (SCRAMBASE), 
is divided into an Admin i st rat ion database (ABASE) module, 
an Equipment database (EBASE) module, and an Operations 
database (DBASE) module. 




SCRAMBASE 




Figure 1.1 SCRAMBASE Concept 
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The OBASE module is comprised schedule and exercise data 
necessary to create a weekly schedule and generate required 
reports. The prototype system designed by this study will 
perform the first three functions, and in doing so will also 
make available all data necessary for accomplishment of the 
fourth . 

In essence, two distinct but interrelated applications 
will be created. The first application will perform those 
functions of the Scheduler related to the gathering and 
input of data into a weekly facilities and personnel employ- 
ment schedule. The final product of this application will be 
a printed schedule of weekly activities. The second applica- 
tion will provide the means for the Program Engineers and 
Operations Analysts to effect the collection and storage of 
data pertaining to the exercises conducted on the ranges. 
Although no printed reports will be produced by the proto- 
type system, all data required for those reports will be 
stored in the database. 

D. METHODOLOGY 

Systems analysis is basically a three phase process de- 
signed to gather and analyze facts pertaining to the exis- 
ting system, with the ultimate goal of improving that system 
through better procedures and techniques. 

During the study phase, information is gathered rela- 
tive to the capabilities and deficiencies of the present 
system . Specific objectives critical in deve loping an under- 
standing of the system are: 

• Identify all knowledge workers who use or are affected 
by the current system. 

• Identify the purpose, goals, objectives and policies 
of the current information system, and analyze the 
extent to which the mission is being achieved. 
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• Identify the information system functions provided by 
the current system and analyze the extent to which 
these functions support the knowledge workers and the 
mission . 



• Separate the current information system i 
components and analyze how these components 
to provide the current information resources. 
[Ref. 2 : pg . 182] 



nto its 
in terac t 



The second phase of systems analysis is that of re- 
quirements definition. The two primary goals of this stage 
are : 



* I den t i f ica t ion of 
and definition of 


the objects the user needs 
their structure. 


to 


track 


• Determina tion of 

application that 


the functional components 

will use the database. [Re 


of 

f . 


eac h 
3 : pg . 



88 ] . 



User requirements will be discussed in Chapter II. 



The third , and 


final phase 


of systems 


ana 1 y s 


is is the 


design phase, which 


consists of 


both logical 


design 


( covered 



in Chapter III) and the implementation of the system (dis- 
cussed in Chapter IV). 

E. FEASIBILITY 
1 . Cost 

The implementation of the prototype system de- 
signed by this study will require a minimum of additional 
funds. Equipment needed for the system is presently on hand, 
and the time and effort required to train system operators 
is expected to be negligible. The limited training require- 
ments are primarily due to the users' existing knowledge of 
the Oracle database system, the Users' Manual and the de- 
signed-in simplicity of the user interface. 

2. Technical 

The only technical limitations imposed by the 
prototype system are those associated with the selection of 
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Professional ORACLE as the designated database management 
system to be employed. The system requirements for use of 
ORACLE consist of: 

• Compaq 386, IBM PC/AT, Personal System/2 Models 50, 60 

and 80, or 100'/. compatibles. 

• DOS 3.1 or later version, or OS/2. 

• Up to 6MB of local hard disk to accomodate all soft- 
ware components and demon s t r a t i on databases. 

• 640 KB of regular RAM plus 896 KB of extended RAM. 

[ Ref . 4 : pg . 10 ] . 

The design, development, documen ta t i on and testing 
of the prototype system was done on IBM-compatible AT machi- 
nes; implementation and further testing will be done at 
FACSFAC on an IBM Model 80. All system requirements listed 
above are currently available at FACSFAC, along with a 
technical support engineer who is intimately familiar with 
the ORACLE database management system. 

3. Schedule 

The prototype system for the 0BASE component of 
SCRAMBASE is being developed concurrently with, yet indepen- 
ently of, the other two components. The latter impose no re- 
strictions on 0BASE development, nor do they more than 
associative ly depend on its development. In that the SCRAM- 
NET plan is a long-term process, it also imposes no schedu- 
ling constraints on the development of this system. Thus, 
from the schedule standpoint, feasibility is assumed. 
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USER REQUIREMENTS 



I I . 

The determination of user needs, in terms of both data 
and functional requi remen ts , is the second step of systems 
analysis. First, in order to understand better the needs of 
the FACSFAC organization, the study phase examines its 
current method of data collection and storage. 

A. PRESENT SYSTEM 

The present system used by FACSFAC was seen as being 
two separate, but interacting a pp 1 ic a t i ons . Figures 2.1 and 
2.2 graphically portray the two applications. In those 
diagrams, a rectangle represents a source/sink, an oval 
represents a function being performed, an arrow shows the 
flow of data and information, and the two parallel lines 
represent a data bank or database. 

The first application consists of those functions 
necessary for gathering and input of various data in order 
to create weekly and monthly schedules of activities for 
FACSFAC facilities and personnel and DYNACORP personnel. The 
scheduler receives the Quarterly Employment Schedule from 
the Naval Undersea Warfare Engineering Station ( NUWES ) 
containing the training needs of the various client com- 
munities. He then creates a monthly planner for internal use 
only, and uses it as a guide for developing the upcoming 
weekly schedules. Using the monthly planner and asset avail- 
abilities from NUWES, the client users and the supporting 
commands, the scheduler generates individual exercise events 
linking FACSFAC facilities with the training requirements of 
the clients. FACSFAC and DYNACORP personnel are then matched 
with the exercise events, and a weekly activities schedule 
is thus created and distributed. Modifications to that 
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schedule are made as needed, based upon inputs from NUWES, 
the supporting commands and clients. 




Figure 2.1 Current Scheduling System. 



The second application consists of those activities 
involved in collecting post-exercise information for the 
purpose of generating required reports and performing ana- 
lyses on the tactical employment data gathered during the 
exercise. In this application, the Program Engineer accumu- 
lates tactical data during the exercise from both personal 
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Figure 3.2 Current Exercise Results Function. 

observation and inputs from the Operations Analyst, Opera- 
tions Controller and range Safety Officer. These data are 
combined with data obtained from the client users during the 
event debrief to create an Exercise Summary document which 
is then filed, an Attack/Exercise Performance Evaluation, 
and a MK46 Rapid Feedback Firing Report, if applicable. The 
Operations Analyst periodically accesses the filed documents 
in order to produce assorted other required reports. 
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B. REQUIREMENTS DEFINITION 

The second stage of systems analysis is that of re- 
quirements definition, wherein the determination is made as 
to exactly what the new system must do. These requirements 
consist of both the data objects which must be captured by 
the system, and the functions that the new system must be 
able to perform. 

1 . Data Requirements 

System data requirements were determined through a 
series of interviews conducted with the prospective system 
users and management at FACSFAC. These requirements were 
then translated into objects, diagrams and specifications. 
Appendix A contains object diagrams, Appendix B the object 
specifications, and Appendix C the definition and other data 
of each domain. 

In keeping with the scope of the project as de- 
scribed in Chapter I, the database system for FASCFAC is 
envisioned as being two primary applications: schedule and 
exercise results. The schedule application will store all 
data relevant to the schedule, but will not perform the 
actual scheduling. The second application, referred to as 
the results application, will store all the results of an 
particular event. In terms of a time line, scheduling is 
concerned with an event before it occurs, and exercise 
results is concerned with post-event analysis. 

a. Schedule Application Objects 

The schedule application stores the schedule 
in an easily updatable form to accommodate the many changes 
that occur during the scheduling process. This is accom- 
plished by breaking the data down into the five entities 
with which the scheduler normally works: the exercise event 
itself, the brief, the users, the weapon and the target. 
These five entities are represented by cor respond ing objects 
of the same names. Of these five objects, the main one is 
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the EXERCISE object, since it contains, directly or indi- 
rectly, all the other objects. This is consistent with the 
view of the FACSFAC personnel who, in most instances, view 
the exercise as one entity, but at other times see each 
object as separate entities. 

The exercise entity is represented by the 
EXERCISE Object which uniquely identifies an instance of an 
exercise ( ref erred to as an event) by the Exercise Type and 
Event Number. Normally, the scheduler concatenates these two 
numbers to form one event identifier. The Exercise Type 
indicates the specific type of exercise to be run, such as a 
submarine torpedo exercise or an S-3 electronic warfare 
exercise. This data is important to the database because 
each exercise has unique information storage r equ i remen ts . 
For example, electronic warfare exercises do not require 
weapons or targets, thus these objects need not be recorded 
as part of the EXERCISE object. The Event Number uniquely 
identifies an individual event within each exercise type. 
This number is a sequential number for each exercise type 
conducted during a given year. The EXERCISE object also 
contains general scheduling information concerning the 
event, such as date and times, personnel, and message re- 
quirements. Required exercise support, in the form of target 
and weapon recovery vehicles, is a 1 so identified in this 
ob j ec t . 

The BRIEF Object consists of information 
relevant to each briefing. Normally, there is a minimum of 
two briefs associated with each event: a pre-event brief and 
a post-event brief. The BRIEF object is used to create a 
Weekly Briefings Report to ensure not only that briefer 
knows when and where his briefings are to be held, but also 
to allow others to schedule the briefing room on an "as- 
available" basis. Each brief is identified by its title. 
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The TARGET Object contains information about 
the target(s) to be used during a given exercise. Creating 
this separate object ensures that the correct target parame- 
ters are being used for each exercise event. The TARGET 
object also contains the information needed to schedule the 
target launch vehicle(s). FACSFAC personnel view this as 
being a separate object, mainly to depict how the infor- 
mation about the targets is received. When the schedule is 
finalized, it is sent to the commands responsible for target 
support, and targets are provided to match the scheduled 
need. The number and type of targets needed for an event 
vary with the type of exercise being conducted and the 
number of participants in a particular event. Thus, the 
TARGET object can be multi-valued within the EXERCISE ob- 
ject. The TARGET object is identified by Exercise Type, 
Event Number and Target Designation. 

The USERS Object contains those attributes 
describing the client users of the range. FACSFAC considers 
this as being an object because each client ship or squadron 
is a unique entity. In this application, at least one client 
command is associated with an exercise event and the USERS 
object describes those command characteristics relevant to 
an event. Each exercise event may have multiple users, to 
include the target itself if it is a ship or submarine. For 
aircraft squadrons the USER object also includes the number 
of aircraft from that command par t ic i pa t ing in the exercise 
event. The USERS object also contains the multi-valued 
WEAPON object. It is identified by Exercise Type, Event 
Number and Command Name. 

The WEAPON Object is very similar to the 
TARGET object, in that it serves the function for weapons as 
the TARGET object does for targets. As the TARGET object is 
multi-valued within an EXERCISE object, the WEAPON object is 
multi-valued within a USERS object, with the normal number 



12 



of weapons being two for each participant in an event. The 
WEAPON object is identified by Weapon Type and Command Name, 
b- Results Application Objects 

The RESULTS Object is the main object of the 
exercise results application. It has the same identifier as 
the EXERCISE object with which it is associated. A great 
deal of the information in the results application is trans- 
ferred from the scheduling application as default data. In 
addition to other attributes, the RESULTS object contains a 
multi-valued attribute, 'reason cancelled', which records 
the reason(s) why an exercise was either partially or en- 
tirely cancelled, and the range utilization hours lost for 
each given reason . The RESULTS object also contains all 
other objects that are part of the Results application. 

The PLATFORM Object stores information about 
the individual unit that conducted an attack. The attacking 
unit can be either a ship, an aircraft or a submarine. 
Additionally, a unit may conduct multiple attacks on a 

target during an event. The PLATFORM object records usage of 

expendable ordnance (sonobuoys) and reasons that scheduled 
weapon drops were not made. This object is identified by 
Exercise Type, Event Number, Command Name and Side Number. 

The ATTACK Object, contained within the 

PLATFORM object, is the heart of the results application. It 

records all information associated with each attack instance 
occurring for a given platform during a particular event. An 
instance of attack can be real, in which an exercise torpedo 
is actually expended, or simulated. The ATTACK object also 
records how well the platform performed in carrying out its 
attack(s). The information stored can be used later to 
evaluate the tactical proficiency of the platform, squadron 
and community. An attack is uniquely identified by a time of 
fire and the associated platform conducting the attack. Data 
recorded in each attack instance includes the accuracy of 
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the platform's solution at the time of the attack, the 
tactical employment of the platform at the time of attack, 
and whether or not the attack was successful. The ATTACK 
object also contains the multi-valued object WEAPON RESULTS. 

The WEAPON RESULTS Object contains informa- 
tion pertaining to weapon performance and recovery, and 
individual instances are identified by the type (mk) and 
serial number of the weapon. The one WEAPON RESULTS attrib- 
ute relevant to the ATTACK object is 'torpedo performance' . 
Should an exercise torpedo malfunction, the platform con- 
ducting the attack cannot be held responsible for the weapon 
missing the target. Thus, the torpedo's performance must be 
recorded in the ATTACK object. The WEAPON RESULTS object 
also contains the LOST object. 

The TARGET RESULTS Object records data about 
the target used during the exercise event and its perfor- 
mance during the course of the exercise. This object is 
identified by the target designation, which is a serial 
number for a range target, or a ship designation or hull 
number if the target was an actual submarine or ship. If a 
ship or submarine is used as a target then the only target 
information that applies are track quality and sound augmen- 
tation information. The TARGET RESULTS object records the 
success or failure of target recovery operations, and also 
contains the LOST object, which stores data about lost 
torpedoes and targets. 

The LOST Object, contained within the TARGET 
RESULTS and WEAPON RESULTS objects, records information 
pertaining to lost torpedoes and/or targets. It is consi- 
dered separate from the WEAPON RESULTS and TARGET RESULTS 
objects because its occurrence is so rare (perhaps three or 
four times a year). Each instance is identified by the 
weapon type (mk) and serial number, or target designation 
and serial number. The LOST object is associated with a 



14 



particular event, thus other needed information for that 
object can be obtained from other objects of that event. 

2. Functional Requirements 

The objects described above reflect the users' 
view of what must be captured in the new system. The func- 
tional requirements specify the actual database application 
requirements of the system, and are portrayed graphically in 
the data flow diagrams (DFD) in Appendix D. 
a. Schedule Application 

The functional requirements of the schedule 
application consist of creating an exercise event and dele- 
ting/modifying an exercise event. The term "exercise event" 
as used here means both the Exercise object and its associa- 
ted objects (Brief, User, Weapon and Target). The creation 
and modification/deletion of an exercise are shown DFD (A) 
and (B), respectively. In creating a new event, the schedu- 
ler gathers data (objects) from the Program Manager, the 
Program Engineer, NUWES and the Supporting Commands. This 
information, combined with the monthly planning schedule 
stored in the 0-Base database, is used to create a single, 
unique exercise event (object). The scheduler forwards 
exercise events for an entire week, in the form of a tenta- 
tive weekly schedule, to the Range Manager for review and 
approval. Any mod i f ica tions to an event by the Range Manager 
are sent back to the scheduler for change and are re-sub- 
mitted for approval. The approved weekly schedule is 
returned to the scheduler who distributes it and issues a 
Weekly Briefings Report, depicting all scheduled briefs for 
the week, including times, locations and briefing officers. 

In the second part of the schedule applica- 
tion, the scheduler receives recommended changes to and 
deletions from events in the weekly schedule. These 
recommendations come from the Program Manager, the Program 
Engineer, the client User Commands, NUWES and the Supporting 
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Commands and are forwarded to the Range Manager for appro- 
val. Upon receipt of approval, the scheduler issues an 
updated weekly schedule and a modified Weekly Briefings 
report reflecting the changes. 

b. Exercise Results Application 

The third DFD portrays the functional re- 
quirements of the Exercise Results application, which con- 
sist of those processes necessary to gather and store exer- 
cise results data. This includes not only the Result object, 
but also the Platform, Attack, Weapon Result, Target Result 
and Lost objects. These data can then be used for user 
performance evaluations and for the creation of periodic and 
aperiodic reports. Data contained in the Exercise event and 
stored in the 0-Base database are retrieved by a clerk and 
combined with post-exercise data from the 0-Base database 
(Results Object) to create an Exercise Summary, which is 
passed to the Program Engineer (PE) for review and approval. 
Also passed to the PE is a list of scheduled exercise events 
in the database which have no cor respond ing Results object. 
The PE files the Summary and takes action to ensure that all 
exercise events have associated Results in the 0-Base data- 
base . The PE also retrieves Platform/Attack data from the 
database in order to produce a Mk-46 Rapid Feedback Firing 
Report for distribution to the user command following the 
exercise. The Operations Analyst and Program Manager 
retrieve Results and Platform data from the database in 
order to create periodic reports for the Fleet Commanders, 
User Commands and for internal FACSFAC distribution. Lastly, 
the c ommun i c a tor , who may also be the PE, creates and 
distributes the Mk-46 Quarterly Firing Report to Naval Sea 
Systems Command . 

The Update, Display and Control Mechanisms 
required for the system are as shown in Appendix E. 
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III. SYSTEM DESIGN 
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Under logical database design, items to be discussed 
include the concepts of relations, primary and foreign keys, 
re 1 at ionships , relationship constraints and normalization. 
In the application design phase, the applications and their 
scope will be addressed, along with control mechanisms and a 
description of the menu hierarchy. 

A. LOGICAL DATABASE DESIGN 

In this step, each object developed in the user's 
requirements phase is translated into one or more two-dimen- 
sional tables, called relations. Each row in a relation is 
called a tuple, and corresponds to a record. Each column is 
an attribute, and corresponds to a field. The relations 
thus created are depicted in Appendix F. A simple object, 
such as Brief or Target, which contains only single-valued, 
non-object properties, is represented by a single relation. 
A composite object, on the other hand, is one containing one 
or more non-object multivalued properties, and requires more 
than one relation for their re presen ta t ion . For example, the 
Result object (Appendix A) contains several non-object, 
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multivalued properties which are translated into the Support 
and Cancel relations given in Appendix F. A compound object 
contains at least one object property, requiring translation 
of that object into several relations, each of which could 
stand on its own. For example, the Exercise object of Appen- 
dix A contains the object properties Brief, User and Target, 
each of which forming its own relation in Appendix F. 

1. Relation Keys 

Each relation has a set of attributes, called the 
key, which uniquely identifies a tuple. These keys are 
underlined. In the Exercise relation the key consists of 
Exercise Type ( Exer ) and Event Number ( Event ) . In all of the 
other relations of the Schedule Application, except for 
Brief, Exercise Type and Event Number appear as part of the 
key, where they represent a foreign key (the key of another 
relation), as indicated by the asterisk. In the Brief rela- 
tion, Brief Title ( Title ) and Brief Time ( T ime ) are the key 
attributes, but the relation contains Exer and Event as a 
foreign key. 

In the Exercise Results Application, Exer and 
Even t are a 1 so common in most of the keys, the exceptions 
being the Attack relation and those multi-valued objects and 
attributes associated with it. Exer and Event are, however, 
present in the Attack relation as a foreign key, as are 
Command and Sideno (comprising the Platform key). Thus, an 
attack can be associated with both an exercise event and a 
specific platform. In a similar manner, the Lost relation, 
with its multiplicity of foreign keys, can be associated 
directly with an exercise, an attack, a weapon and/or a 
targe t . 



2. Relationships 

A binary relationship is 
two record types. Whereas an object 
to-one basis into a relation 
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relationships between those record typ 
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Figure 3.1 Schedule Application Relationships 
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Figure 3.2 Results Application Relationships 

3. Relationship Constraints 

Another notation used in Figures 3.1 and 3.2 and 
in Appendix F is one to indicate a mandatory or optional 
relationship between two record types. A circle at the end 
of a line indicates an optional association. For example, an 
exercise may have a target (or more than one) associated 
with it, and a platform may conduct one or more attack. A 
bar at the end of the connector indicates a mandatory rela- 
tionship. For example, a weapon results relation (WEAPONR) 
must have an attack associated with it. 
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The exercise and brief re 1 a t i onshi ps are optional 
in each direction. This is because an exercise may have only 
one brief associated with it (rather than the normal two), 
or, in the case of a range maintenance period (designated as 
an exercise for scheduling purposes), there may be no sched- 
uled brief at all. Additionally, a brief may be scheduled 
that does not relate to a specific exercise. 

4. Normalization 

The relations created in this project are all in 
at least third normal form ( 3NF ) . A relation can be con- 
sidered as being in 3NF if (1) all non-key attributes are 
dependent on all of the key, and (2) if it contains no 
transitive dependencies. For example, in the case of the 
Target relation, the Geometry, Acoustics, Tpinger and 
Lnchveh attributes are each dependent on Exer , Event and 
Tq tdesiq and only on those attributes. 

B. APPLICATION DESIGN 

Data flow diagrams (DFD) were developed during the user 
requirements phase in order to identify the functional needs 
of the organi zat ion . In the application design step, these 
DFDs are transposed into a functional hierarchy structure, 
as shown in Appendix G. Each block or module 3 

object or function, and each module contains sub-modules, 
selection of which will result in a specific task being per- 
formed. These hierarchy structures also serve to delineate 
the applications and the scope of the project, which have 
been well-defined in previous chapters and will not be 
repeated here. 
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1. Control Mechanisms 

After determining the number and scope of the 
applications , the next step in application design is to 
devise the control mechanisms associated with the applica- 
tions. A menu-driven application is considered to be the 
most appropriate control mechanism for this project, due 
primarily to its simplicity of design and ease of use. 
Minimum time will be necessary to train the operators in the 
use of the menus, because they are sel f -ex p 1 ana tory . Addi- 
tionally, a menu driven application is far easier to under- 
stand than one which is command-driven. 

2. Menu Hierarchy Descriptions 

The final stage of application design consists of 
converting the entity-relationship structures into a series 
of menus. A set of menus is perhaps the easiest method of 
providing user interface with the application functions. 
Additionally, they simplify user learning, und er s tand ing and 
utilization of the system. Examples of the various menus 
cor respond ing to the hierarchic structures are illustrated 
in the figures and described below. 

a. Main Menu 



The 


main 


0-Base menu 


shown 


in 


Figure 


3.3 


allows the user to 


se 1 ec 


t which appl 


ica tion 


to 


enter, 


or 



permits him to exit back to the operating system. As men- 
tioned above, permission to enter a selected function will 
be governed by the password of the user. 
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MAIN O-BASE MENU 


\ 




Schedule Application 1 






Results Application 2 






Exit to System 3 




V 


Enter Desired Selection: 


J 



Figure 3.3 System Main Menu 

b. Schedule Application Menu 

The Schedule Application menu (Figure 3.4) 
provides the user with the options of selecting an item 
within the schedule application for update, or performing 
one of the two print functions associated with the applica- 
tion. The user also has the option to exit to the main menu. 
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SCHEDULE APPLICATION MENU 


Event 
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Weapon 
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Target 
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Print Schedule . . 


6 


Print Brief Rpt . . 
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EXIT TO MAIN MENU . 
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Enter Desired Seleotlon: 
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. 



Figure 3.4 Schedule Application Menu 

b. Schedule Functions Menu 

Following selection of an object to update 
from the previous menu, the user is presented with a menu 
displaying the various functions available (Figure 3.b). 

When creating (adding) an event, the user enters all known 
data associated with that event, including brief, user, 
weapon and target information. Additionally, a brief can be 
added, modified or deleted individually. Modification of 
user, weapon and target data associated with an existing 
exercise event is accomplished through modifying the event 
itself. Deletion of an event deletes all user, weapon, 
target and brief information associated with that event. 

The user also has the option to execute user — defined queries 
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on each of the exercise objects. Lastly, the user can either 



exit to the previous menu or exit to the main menu. 



SCHEDULE FUNCTION MENU 


Add 


1 


Modify 


2 


Delete 


3 


Query 
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EXIT TO SCHED MENU . 
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EXIT TO MAIN MENU . . 


. 6 


Enter Desired Selection : 





Figure 3.5 Schedule Functions Menu 

c . Exercise Results Application Menu 

This menu (Figure 3.6) permits the user to 
enter into the second application of the system — the 
Exercise Results application. When a selection is made of 
one of the objects associated with the results application, 
the user is presented with a Results Functions menu similar 
to the one for the Schedule application (see Figure 3.5). It 
is through the functions menu that the update of the selec- 
ted object is performed. Add i t iona 1 1 y , the user has the 
option of selecting a Report Generator function from this 
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menu. Although beyond the scope of this project, future 
enhancements to the system could permit automated reports 
through this function. The user also may exit back to the 
main menu. 



RE8ULT8 APPLICATION 
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Exercise Result . . . . 
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Figure 3-6 Results Application Menu 

If the user desires to create a new exercise 
result, he selects "Exercise Result" from the Results Ap- 
plication Menu, followed by "Add" from the Results Functions 
Menu. He is then cycled through all relevant objects as- 
sociated with the new exercise result. Individual objects, 
such as Attack, are added in the same manner. Deletion of a 
Platform requires prior deletion of any Attack and Weapon 
associated with that platform. Deletion of a Result will 
cause the deletion of all objects associated with it. Any 
other object may be deleted individually. 
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IV. SYSTEM IMPLEMENTATION 

A. INTRODUCTION 

The second step in the design phase, and the final step 
in the systems analysis cycle, is implementation. The main 
task of of implementation is to construct a system according 
to the design. In this step, the relations, rows and at- 
tributes of the design phase are translated into DBMS-speci- 
fic tables, records and fields. 

Based on application design, the application develop- 
ment tools of Oracle are used to construct the forms, re- 
ports and menus needed in the system. The Oracle DBMS will 
be addressed after a discussion of table and screen 
gener a t ion . 

1. Database Tables 

Data requirements were identified during the user 
requirement phase and were presented in the form of objects. 
During the logical design phase of the last chapter, the 
objects were translated into cor respond ing relations, and 
relationships between the relations were established. In the 
implementation phase, these relations are translated into 
DBMS-specific (Oracle) tables. These tables are the essence 
of data storage and management in the database management 
system. Each table consists of a series of columns, or 
fields, which equate to the attributes of the logical rela- 
tions. A single row of data within a table is referred to as 
a record . 

A listing of all tables created for this project 
is found in Appendix H. The first section of the appendix 
contains those tables necessary for the storage and display 
of the actual data, while the second section contains the 
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look-up tables designed to assist the user in making proper 
entries in various fields. 

Appendix I presents the associations between the 
descriptive names, domain names and actual table field names 
for each object. 

2. Screen Designs 

The second task of the user requirements phase was 
the identification of the functional requirements of the 
system. The task was accomplished by the creation of a 
series of data flow diagrams ( DFD ) . The logical design phase 
converted the DFDs into menus that allowed the user to 
control the insertion, modification and deletion functions. 
During the implementation phase, the menus are translated 
into screens, or views, which provide the user the actual 
mechanisms for update and display of the data. The screens 
are the ma ter ia 1 i za t ions of the objects, containing selected 
rows and columns of the underlying tables. In some cases, a 
single screen consists of two or more joined tables. Because 
these screens are not stored as actual physical tables, the 
views can be termed virtual tables. Appendix J contains the 
various screens developed for the two app 1 ic a t ions . The 
following section describes the DBMS used for implementation 
of this project. 

B. ORACLE RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS) 

Oracle is an extremely powerful, Standard Query Lang- 
uage (SQL)-based relational database management system. The 
Oracle corporation has added non-standard extensions to the 
SQL language, thus term their product " SQL tP 1 us " . Due to its 
utility at both the stand-alone mic rocompu ter level and the 
network level, and its high degree of portability, it was 
selected by FACSFAC as the program of choice for their 
automated database system. Hardware and system requirements 
of Oracle were presented in Chapter I. 
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inc 1 tide 



The Oracle products include a variety of applications 
development and generation tools, providing 



complete facilities that systems designers and devel- 
opers can use to design, develop and test software 
products whose engine is the Oracle RDBMS. [Ref. 5 : pg . 
x x v ] 



The most significant tools used in this project include 
SQL*Plus, SQL*Forms and, to some extent, SQL*Report. 

1- SQL*Plus 

The developer uses the SQL*Plus query language to 
"create, store, modify, retrieve, print and manage informa- 
tion in an ORACLE database" [Ref. 6:pg. i]. Of all the pro- 

grams in the Oracle system, it provides the most direct 
access to the data. It is through this tool that the tables 
were created and the data was inserted into the tables. 

2. SQLIForms 

This tool is used by both the system developer and 
the system operator. The developer selects the rows and 
columns of the tables for display in screens through the use 
of the SQL*Forms program. This portion of the program is 
called Design forms. After the form has been generated, the 
Run form procedure permits the operator to work with the 
information that the form accesses. Once the form is dis- 
played, the operator is able to perform the logical menu 
functions of insertion, deletion and modification described 
in the previous chapter. 

3. SQL*Report 

Like SQL*Forms, this program also has two utili- 
ties. The Report Text Formatter ( RPF ) is "a genera 1 -pur pose 
text formatter for a variety of word processing applications 
...." [Ref. 7 : pg . 9]. The second utility is the Report 
Generator (RPT), which enables the developer to extract 
specific data from the database and include it in a report. 
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RPT must be used in conjunction with some type of text 
formatter, such as RPF . 

A far more powerful report generator, SQL*Report- 
writer, has recently been marketed by the Oracle corpora- 
tion , but was unavailable for this project. 

C - SOFTWARE DOCUMENT AT I ON 
1. User Manual 

The user manual written for this system is provi- 
ded in Appendix K. It is designed for a user familiar with 
the Oracle RDBMS, having had, as a minimum, attended an 
operator training course or read an operator tutorial. 
Because implementation of the system does not lend itself to 
a menu layout in the Oracle environment, the logical menu 
functions described in the previous chapter are performed 
through the activation of various keyboard keys. The func- 



tion keys and 


spec ial-pur 


pose 


keys used by 


□rac 1 e 


and /or 


custom-designed 


for this 


sys 


tern are defined 


in the 


user 


manual . A 1 so i 


nc 1 uded in 


the 


manual are the 


various field 



constraints, formats and masks which must be adhered to 
while creating new records. 

2. Main Program 

The program developed for this project is written 
in SQL, a powerful fourth generation language ( 4GL ) . Because 
it is a 4GL , standard program descriptions (structure 
charts, etc.) and subroutines are not applicable to the 
actual design. The length of the program precludes its 
incor porat ion as an appendix. 

D. REPORTS 

The operator has the option to print two standard, 
automated reports through the system: i) a weekly schedule 

of activities, and 2) a weekly briefings report. These 
reports were created using SQL*Report. An example of each is 
presented in Appendix L. 
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V. 



CONCLUSIONS AND RECOMMENDATIONS 



A- SUMMARY AND CONCLUSIONS 

The amount and complexity of the operational data 
collected and stored by the Fleet Area Control and Surveil- 
lance Facility will soon overwhelm the manual data handling 
capabilities of the command. This study develops a relation- 
al database system prototype to assist the organization in 
those critical areas of its activities. One of the main 
goals is to increase the speed and accuracy of data input, 
thereby enhancing the effectiveness and productivity of the 
unit. Add 1 1 iona 1 1 y , a powerful database query function and a 
report generation capability will greatly facilitate user 
pe r f or mance . 

The system is viewed as being two separate but interac- 
tive appl ications . The scheduling application is used to 
input, modify and delete data elements associated with 
creation of a weekly schedule of activities and a weekly 
briefings report. The results application is designed to 
allow for the input, modification and deletion of operation- 
al data gathered during the execution of various scheduled 
exerc i ses . 

The power and flexibility of ORACLE made it the program 
of choice by FACSFAC for their database system. Despite its 
advantages, ORACLE is difficult to apply for the novice 
user, thus a detailed Users Manual is provided in Appendix K 
to assist the operator. The prototype system was designed 
with the goal of making it as easy as possible to understand 
and use, however a certain level of operator knowledge of 
ORACLE is assumed. The Users Manual contains a section 
describing the various function keys and their applications 



31 



in ORACLE, as well as the special purpose keys custom de- 
signed into the prototype model to make it user-f r i end 1 y . 

B. RECOMMENDATIONS AND FUTURE WORK 

Establishment of a relational database allows for 
future expansion and capability enhancements. Using data 
gathered and stored in the results application, SQL*Report- 
writer can be used to develop an automated report generation 
capability for the operations analyst. Additionally, the 
system can be enhanced through the incor pora t i on of an 
automatic scheduling and conflict resolution decision sup- 
port program. Development of these two augmentations to the 
prototype will serve to increase command efficiency even 
further. Finally, the ability of ORACLE to be utilized in a 
network environment conforms well with the strategic infor- 
mation technology goals of the organ i z a t ion . Development of 
an interactive network linking the three databases is open 
for further study. 
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APPENDIX A 



RELATIONAL DATABASE OBJECTS 



EXERCISE OBJECT 




BRIEF OBJECT 


Exercise Type 




Brief Title 


Event Number 




Date and Time 


Exerc i se Desc rip t ion 




Location 


Scheduled Start Time 




Br ief er 


Scheduled Stop Time 




MOCS Start Time 




TARGET OBJECT 


liQCS Stop Time 






Operational Area 




* Exercise TvDe 


Exc lusive 




* Event Number 


Primary Tgt Recovery 




Tarqe t Desiqna t ion 


Secondary Tgt Recovery 




Target Geometry 


Primary Wpn Recovery 




Acoustics Code 


Secondary Wpn Recovery 




Pinger Channel 


Weapon Haulback 




Launch Vehicle 


Tracking Type 




Project Engineer 




WEAPON OBJECT 


Operation Controller 






Operation Analyst 




Weapon Type 


Safety Officer 




* Command Name 


Green Message Required 




Number Scheduled 


Green Message Sent 




Pinger Channel 


Submarine Rel axat ion 




Message Required 




USERS OBJECT 


Air Space Allocated 






Commun ica t ions 




* Exercise Type 


Commen ts 




* Event Number 


BRIEF MV 




Command Name 


USERS MV 




Number of Units 


TARGET MV 




EATS Transponder 


RESULTS 




Pinger Channel 




WEAPON MV 
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RESULTS OBJECT 



Exercise Type 
Event Number 
Exercise Description 
Exercise Attainment 
Comex 
Finex 

Scheduled Start Time 
Scheduled Stop Time 



Oparea 
Visibility 
Sea State 

Reason Canceled MV 

Hours Lost MV 

Cancel Start Time MV 
Support Platform MV 
Support Sidenumber MV 
Support Used MV 



Classified Comments 
Unclassified Commen ts 

PLATFORM MV 

TARGET RESULTS MV 



LOST OBJECT 

FuT 

Mod 

Serial Number 
* Time Lost 
La t i tude 
Long i tude 
I mp 1 os i on 
Water Depth 



TARGET RESULTS OBJECT 



* Exercise Type 



* Event 1 


Number 


Taraet 


Desianat ion 


Mk 

Serial 


Number 


Mod 

Geometry 


Target 


Per f ormance 


Launch 


T ime 


Target 


Recovered 



Recovery Vehicle 
Sound Level 
Frequency 
Track Quality 

LOST MV 



WEAPON 


RESULTS OBJECT 


* TOF 




* Mk 




Mod 




Ser ia 1 


Number 


Torped 


o Performance 


Searc h 


T ime 


Weapon 


Recovered 


Recove 


ry Vehicle 


Recove 


ry Time 


Bring 


Back Vehicle 


T rack 


Qua 1 i ty 


LOST 


MV 
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r 



ATTACK OBJECT 



* 

* 






T ime of Fi re 
Command Name 
Side Number 
Start Op 

Actual Target Course 
Actual Target Bearing 
Actual Target Speed 
Actual Target Range 
Actual Target Depth 
Target Maneuver Time 
Target Maneuver 
Course 

Target Maneuver Speed 
Target Doppler 
Solution Bearing 
Solution Course 
Solution Speed 
Solution Range 
Heading at TOF 
Speed at TOF 
Mode 

Sonar Setting 
Contact Type 
Acqui red 
Eval of Attack 
Search Depth 
Commen ts 
A 1 1 1 tude 
Delivery Method 
Ph 

Bearing to Splash 
Point 

Range to Splash 
Point 
Acqui red 
Eval of Attack 
Search Depth 
Comments 



WEAPON RESULTS 



PLATFORM OBJECT 


* Exercise Type 




* Event Number 




Command Name 




Side Number 




Showed Up 




Track Quality 




Lof ar 




Di far 




Dicas 




Vlad 




Weapon Assigned 


MV 


Number of Weapons 


MV 


No Drop 


MV 


ATTACK 


MV 
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APPENDIX B 



OBJECT DEFINITIONS 



EXERCISE OBJECT 

Descriptive Name Domain Name 



Exercise Type 
Event Number 
Exercise Description 
Schedule Start Time 
Schedule Stop Time 
MOCS Start Time 
MOCS Stop Time 
Operational Area 
Exclusive Use 
Primary Target 

Recovery Vehicle 
Secondary Target 

Recovery Vehicle 
Primary Weapon 

Recovery Vehicle 
Secondary Weapon 

Recovery Vehicle 
Weapon Haulback 
Vehic 1 e 
Tracking Type 
Project Engineer 
Operation Control ler 
Operation Analyst 
Safety Officer 
Green Required 
Green Sent 

Submar ine Relaxation 
Message 
Air Space 
Commun icat ions 
Commen ts 



Exer 
Even t 
Exdesc 

T ime-Schstar t 
T ime-Sc hs top 
Time-MOCS Start 
Time-MOCS Stop 
Oparea 
Exc 1 usi ve 

Recovery-Pr i 

Recovery-Sec 

Rec over y-Pr i 

Recovery-Sec 

Recovery-Hau 1 bac k 
Tracking Type 
Personnel -Pe 
Personnel -Oc 
Personnel -Oa 
Personne 1 -So 
Message-Req 
Message-Sen t 

Message-Sub 
Air Space 
Commun icat ions 
Commen ts 



BRIEF: 

USERS: 

TARGET: 

RESULTS: 



BRIEF object; MV 
USER object; MV 
TARGET object; MV 
RESULTS object 



37 



BRIEF OBJECT 



Descriptive Name 


Domain Name 


Brief Title 
Brief Time 
Location 
Br ief er 


Brief Title 
T ime-Brief 
Location 
Personnel -Brief 



USERS 


OBJECT 


Descriptive Name 


Domain Name 


Exercise Type 
Event Number 
Command Name 
Number of Units 
EATS Transponder 


Exer 
Even t 
Command 
Number-U 
T ransponder 



Pinger Channel Pinger-U 

WEAPON: WEAPON object MV 



TARGET 


OBJECT 


Descriptive Name 


Domain Name 


Exercise Type 

Event Number 

Target Designation 

Geometry 

Acous t ics 

Pinger 

Launch Vehicle 


Exer 
Even t 

Target Designation 
Geometry Code 
Acous t ics 
Pinger-T 
Launc h 



WEAPON 


OBJECT 


Descriptive Name 


Domain Name 


Mk 

Command Name 
Number Scheduled 
Pinger 


Mk 

Command 
Number-S 
Pinger — W 
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RESULTS OBJECT 



Descriptive Name 




Domain Name 


Exercise Type 




Exer 


Event Number 




Event 


Exercise Description 


Exdesc 


Comex 




T ime-C 


F inex 




T ime-F 


Scheduled Start Time 


T ime-Schstart 


Scheduled Stop Time 


T ime-Sc hs top 


Operational Area 




Oparea 


Visibility 




Visible 


Sea State 




Seasta te 


Reason Canceled 


MV 


Cancel ed 


Hours Lost 


MV 


Hours 


Cancel Start Time 


MV 


T ime-Cance 1 


Support Platform 


MV 


Command 


Support Side No. 


MV 


Sidenumber 


Support Used 


MV 


Used 


Classified Comments 


Commen ts 


Unclassified Commen ts 


Commen ts 



PLATFORM; PLATFORM object; MV 

TARGET RESULTS; TARGET RESULTS object; 



PLATFORM 

Descriptive Name 

Exercise Type 
Event Number 
Command Name 
Side Sumber 
Showed Up 
T rac k Qua 1 i ty 
Lof ar 
Di f ar 
D ic ass 
Vlad 

Weapon Assigned 
Number of Weapons 
Sc hedu 1 ed 
No Drop 

ATTACK; ATTACK obj 



OBJECT 

Domain Name 



Exer 
Even t 
Command 
Sidenumber 
Showed 

T rac k Qua 1 i t y 
Sonobuoy no. 
Sonobuoy no. 
Sonobuoy no . 
Sonobuoy no. 
MV Mk 

MV 
MV 

ec t ; MV 



Number-S 

Nodrop 



TARGET RESULTS OBJECT 



Descriptive Name 


Domain Name 


Exercise Type 
Event Number 
Target Designation 
Nod 

Serial Number 
Target Performance 
Geometry 
Launch Time 
Target Recovered 
Recovery Vehicle 
Sound Level 
Frequency 
Track Quality 
LOST; LOST object 


Exer 
Even t 

Target Designation 
Nod 

Serial Number 

Target Performance 

Geometry Code 

T ime-L 

Recovered 

Recovery 

Sound 

Frequency 

T rack Qual i ty 


WEAPON RESULTS 


OBJECT 


Descriptive Name 


Domain Name 


T ime of Fire 

Nk 

Nod 

Serial Number 
Torpedo Performance 
Search Time 
Weapon Recovered 
Recovery Vehicle 
Recovery Time 
Bring Back Vehicle 
Track Quality 
LOST; LOST object 


TOF 

Nk 

Nod 

Serial Number 
Tor pper f 
Search-seconds 
Recovered 
Recovery 
Ninutes-Recover 
Recovery 
Track Quality 



LOST OBJECT 



Descriptive Name 


Domain Name 


Nk 

Nod 

Serial Number 
Time Lost 
La t i tude 
Long i tude 
Implosion 
Water Depth 


Nk 

Nod 

Serial Number 
T ime-Lost 
La t 
Long 

Depth- Imp 
Dep t h-Wa ter 
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ATTACK OBJECT 



Descriptive Name 



Domain Name 



T ime of Fire 
Command Name 
Start Op 

Actual Target Course 
Actual Target Bearing 
Actual Target Speed 
Actual Target Range 
Actual Target Depth 
Target Maneuver Time 
Target Maneuver 
Course 

Target Maneuver 
Speed 

Target Doppler 
Solution Bearing 
Solution Course 
Solution Speed 
Solution Range 
Heading at TOF 
Speed at TOF 
A 1 1 1 tude 
Mode 

Sonar Setting 
Contact Type 
Delivery Method 
Bearing to Splash 
Point 

Range to Splash 
Point 
Acquired 
Eval of Attack 
Search Depth 
Comments MV 

Line Number MV 

WEAPON RESULTS; WEAPON 



T ime-T of 
Command 

T ime -Start- time 

Compass-Tc 

Compass-Tb 

Kts-Ts 

Range-T 

Dep t h-T 

Minutes-Maneuver 

Compass-T m 

Kts-Tm 

Doppler 

Compass-Sb 

Compass-Sc 

K ts-S 

Range-S 

Com pass -He ad ing 

Speed 

Height 

Modecode 

Sonar 

Contact Code 
Delivery Code 

Compass-Sp 1 ashp t 

Range-Splashpt 
Acquired 
Eval 
Dep th-S 
Comments 
L inenumber 
RESULTS object; 
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APPENDIX C 



DOMAIN DEFINITIONS 



Acoustics Code: 
char ( 1 ) 
range: V, N 

Indicates whether or not the target acoustics are those 
requi red . 

Acquired : 

number (1), integer 
range: 0-9 

The number of times that the torpedo acquired the 
target. 0 if it did not acquire the target. 

Air Space: 

char ( 5 ) 
mask : LL-UU , 

where LL is in {00... 99} and UU is in {01... 99} 
Indicates the altitude range reserved in the opera- 
tional area for pa r t i c i pa t i n g aviation units. 

Brief Title: 

char (20) 

The title of the exercise brief to be given. 

Canceled : 

char (25) 

One of 6 reasons why an event was cancelled (asset 
availability, fouled range, in t rumen ta t ion , wea- 
ther, no air tracking, no show). 

Command : 

char ( 8 ) 

The designation of the command ( ie VP-44, SSN-680 ) . 

Commen ts : 

c har ( 75 ) 

Narrative remarks pertaining to the exercise and the 
exercise results. 

Commun ica t i ons : 
char ( 3 ) 

range : in { UHF ' , ' VHF ' , 

Frequency range to be used 
Def au 1 t : UHF 
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' HF ' } 

for exercise communications. 



Compass : 

number (3), integer 
range: 000-359 

Measured in degrees true, except for splashpt. 

Heading: the heading of the platform at TOF. 

Sb: the platform's solution bearing to target. 

Sc: the platform's solution course for the target. 

Splashpt: relative bearing of the weapon splash point 

from the target. 

T a: the course programmed into the torpedo. 

Tb: the true bearing from platform to the target at 

TOF . 

Tc: the true compass heading of the target. 

Tm: the new course of target after it maneuvers if 
maneuver occurs after TOF and while torpedo 
is running . 



Contact Code: 
c har ( 12 ) 

Indicates how the platform detected and maintained 

contact with target (mad, difar, dicass, ro , 
lofar, dipper, surfpass, surfact, ir, vectac, 
spherical, hull, towed array). 

Delivery Code: 
char ( 5 ) 

range: svtt, rtt (asroc), hover, flyin, tt, asroc 

How the torpedo was delivered to the splash point. 



Depth : 

number ( 4 ) 
range: 0-9999 

T: the depth at which the target is set to run. 

S: the depth at which the torpedo is set to search. 

Imp: the depth at which the torpedo/target imploded 

(set to 0 if implosion depth is unknown). 

Water: the depth of the water at site of a lost weapon 

or target. 



Doppler: 

char ( 1 ) 
range: 1-5 

A code describing the type and amount of doppler that 
the target has. [ (1) > 5kts, (2) 2.5-5.0kts, (3) 

2. 5-(-2. 5) kts, (4) (-2. 5)-(-5.0) kts, (5) < 5kts]. 



char ( 10 ) 

Evaluation as to whether the torpedo hit the target, 
(hit, prob hit, prob miss, miss, unknown). 
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Even t 



number ( 5 ) 

mask: YYNNN, where YY are the last two digits in the 

year and NNN is the sequential number of that 
exercise conducted during that year. 

The user-genera ted code identifying the specific exer- 
cise. 



Exa t ta in 
c ha 
ran 
I nd 



Exc lusi v 
c ha 
ran 
I nd 

Exdesc : 
c ha 
Nar 



Exer : 

c ha 
mas 
The 



F requenc 
c ha 
ran 
I nd 



Geometry 

cha 

The 



r (i) 
ge : Y , N 

icates whether or not the range achieved its objec- 
tive for the exercise, i.e., the proper services. 

e : 

r (i) 
ge : Y , N 

icates whether or not the event has exclusive use of 
the operational area. 

r (12) 

rative description of the exercise to be conducted. 
Derived from exercise publications. 



r ( 4 ) 

k: ANNN, where A is char 
designation of the type 
ted. Derived from exer 

Y : 



r (2) 




ge: NB , BB 




icates whether the 


targ 


narrow band ( NB ) 


or br 


if designation is 


a shi 



and N is digit 
of exercise to be conduc- 
cise publications. 



et is transmitting mainly 
oad band (BB) sounds. N/A 

P • 



Code : 
r (4) 

code for the geometry programmed into the target. 
(N/A if designation is a ship or submarine). 



Height : 

number ( 5 ) 
range: 0 - 99,999 

The height at which the Mk-46 torpedo was launched. For 
surface ship, Height = 0. 
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Hours : 

number (2,1) 
r ange : .1 - 99 

Number of hours that were lost for a specific reason 

canceled. Recorded as hours and tenths of hours. 
Total of all cancelled hours can not exceed dif- 
ference between scheduled start time and scheduled 
stop time. 



Kts : 

number (2) 

range: 0-99 

Speed measured in kts. 

Ts: the actual speed of the target at TOF. 

Tm: the speed of the target after maneuver, if maneuver 

occurs after TOF and before end of torpedo run. 

Ss: the platform's solution of speed for the target. 

La t : 

char ( 10 ) 

Template: dd:mm:ss N, where dd is degrees, mm min- 

utes, ss seconds. 

range: dd 20 - 40 

mm 0 - 59 
ss 0-59 

The latitude at which the target or weapon was lost. 
All latitudes are assumed to be north (N). 

Launc h : 

char ( 7 ) 

The designation of the launch vehicle for the exercise 
target. N/A if the target is a surface ship or an 
actual submarine. 



L inenumber : 

number (3), integer 

Identifies unique line number of comments. 

Loca tion : 

char ( 20 ) 

Provides the location of the brief. 

Long i tude : 

char ( 9 ) 

template ddd:mm:ss W 
range: dd 0 - 180 

mm 0 - 59 

ss 0 - 59 

The longitude at which the weapon or target was lost. 
All longitudes are assumed to be west (W). 
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Message : 

char ( 1 ) 
range: V, N 

Req : indicates whether or not a “green" tasking mes- 
sage needs to be sent to the participants in the 
exercise . 

Sent: if Req = V, indicates whether or not the tasking 

message has been sent. N/A if Req = N. 

Sub: indicates whether or not a submarine relaxation 

message is required for the exercise. 



Minutes : 

number (2,1) 

range: 0.0 - 60.0 

Maneuver: the time in minutes after TOF at which the 

target maneuvers. If no maneuver while the torpedo 
is running then 0 is entered. If maneuver occurs 
at TOF enter 0.1. If 0 IS entered, skip target 
maneuver course and speed. 

Recover: the number of minutes expended by the reco- 

very vehicle in retrieving the weapon following 
the exercise. 

Search: the number of minutes that the torpedo was 

engaged in searching for the target. 

Mk : 

char ( 8 ) 

range: legal real/simulated weapons or targets from 

look up tables. The mk of the weapon or target. 



Mod : 

char ( 5 ) 

range: legal mods for the selected torpedo 

The mod of the torpedo. 



Modecode : 

char (6) 

range: snake' or 'circle' 

Mode the torpedo uses in its search. 



Nod rop : 

char ( 1 ) 
range: a - i 

Letter code to indicate why the participant did not 
fire all of his scheduled weapons. (a- platform 
problems, b- torpedo problems, c- weather, d- 
inadequate recovery assets, e- time constraints, 
f- fouled range g- inadequate TMA , h- pinger 
problem, i- other). 
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Number : 



number ( 1 ) 

S: the number of weapons scheduled to be dropped. 

U: the number of units par t ic i pa t ing in an exercise 

from a given command. 

Oparea : 

char ( 6 ) 

User — generated title for the area in which the exercise 
will be conducted. 

Personnel : 

char ( 10 ) 

Brief: briefer assigned to conduct designated brief. 

0a: operations analyst assigned to the exercise. 

Op: operation controller assigned to the exercise. 

Pe: project engineer assigned to the exercise. 

S: range safety officer assigned to the exercise. 

Ph.- 

number (3) 
r ange : 0-100 

Percent rating of the placement of the weapon. 

Pinger : 

char ( 4 ) 

range: in { ' nA' , 'nB' , ' nAnB' } , where n is an integer 



Indicates number of and 
signed to a resource 


c hanne 1 ( s ) 


of 


pinger ( s ) as- 


T: 


indicates the number 
the target. 


and channel 


of 


the pinger in 


U: 


indicates the number and channel 
the par t ic l pa t ing user submarine 


of 


pinger used by 


W: 


indicates the number 


and channel 


of 


the pinger in 



the weapon . 



Range : 

number ( 5 ) 
range: 0 - 99,999 

Measured in yards. 

S: the platform's solution of the distance at TOF. 

Splashpt: distance from the splash point to target. 

T: actual distance of target from platform at TOF. 

Recovered : 

char ( 1 ) 
range: Y, N 

Indicates whether or not the object has been recovered. 
If N, then the LOST object is used. N/A if target 
designation is a ship . 
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Recovery : 

char ( 8 ) 

The designation of the recovery vehicle for the object 
(ie TRW-768 or HC-1563). N/A if target designa- 
tion is a ship. 

Haulback: the designated weapon haulback vehicle. 

Pri: primary recovery vehicle. 

Sec: secondary recovery vehicle. 

Search-seconds: 
number (3) 
range: 0 - 999 

The amount of time the weapon was in its search phase. 

Seas ta te : 

number ( 1 ) 
range: 0-9 

The sea state as measured by the beaufort scale. 

Serial Number: 
char ( 7 ) 

The serial number of the torpedo. 

Showed : 

char ( 1 ) 
r ange : Y , N 

Used to indicate whether or not the scheduled platform 
showed up for the exercise. 



S idenumber : 

char ( 7 ) 

The number on 
t i f y it. 
squad r on 



the side of an 
Used only 



aircraft to uniquely iden- 
if command is a aircraft 



Sonar : 

char (7) 

range: 'active', 'passive', 'combo', 'actpass' 

The type of sonar detection used by the torpedo. 



Sonobuoy no . : 

number (3) 
range: 0 - 999 

The number of sonobuoys of a particular type dropped by 
a platform. 



Sound : 

number (3) 
range: 0 - 999 

Sound level of target measured in dB; or, the augmenta- 
tion sound level if the target is a ship. 
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Speed : 

number (3) 

range: 0 - 500 kts 

Speed of the platform at time of attack. 

Target Designation : 
char ( S ) 

Indicates the type of target used in the exercise. 
Target Per f ormance : 
char (20) 

Objective evaluation of target performance during the 
exercise. ("Did Not Run", "Floater", etc.). 



T ime : 

char ( 14 ) 

mask: ddhhmmZ MONyy 

Brief: scheduled brief time. 

C: the time an event actually starts from the point of 

view of the range. (Default: sched start time). 

F: the time an event actually finishes from the point 

of view of range. (Default: sched finish time). 

Lost : 

Range: comex to finex 

Time at which the weapon or target was lost 
L : 

Range: comex to finex 

Time at which the target is launched. 

MOCS start: scheduled man-up time for range personnel. 
MOCS stop: scheduled shut-down time for range per- 

sonnel . 

Schstart: scheduled exercise start time. 

Schstop: scheduled exercise finish time. 

Start : 

Default: comex 

Range: comex to finex 

Time at which the platform started searching for 
the target which resulted in this attack. 

Tof : 

Default: Date part to comex. 

Range: comex to finex. 

Time of fire of a weapon. 

Tor pper f : 

char (20) 

Indicates the performance of the weapon after launch. 

(normal run, erratic run, did not run, sank at 
launch point, sank at end of run, damaged). 
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T rack Qua 1 i ty : 
number (3) 
range: 0 - 100 

The percent evaluation of the quality of the range's 
track of the object. (0 = no track, 100 = perfect 
t rac k ) . 

Tracking Type: 
char ( 1 ) 

range: in {e, i, b} 

The type of tracking to be used during the exercise. 

(e = EATS, i = in-water, b = both). 

T ransponder : 
char ( 4 ) 

range: IPIP, SIP, SAIP 

Indicates the type of transponder with which the plat- 
form is equipped. N/A for submarines. 



Used : 

char ( 1 ) 
range : Y , N 

Indicates whether or not a scheduled support platform 
was used during the event. 



Visible : 

number (2) 
range: 0 - 99 

The visibility on the range in nm. (99 = unlimited). 
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APPENDIX D 



DATA FLOW DIAGRAMS 



A. 




CREATE NEW EXERCISE EVENT 
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B. 



Updated Weekly Schedule 




MODIFY/DELETE EXERCISE EVENT 
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c. 




RESULTS APPLICATION 
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APPENDIX E 



UPDATE « DISPLAY AND CONTROL MECHANISMS 



A. Schedule Application 



EXERCISE OBJECT 
Display Mechanisms 



I. Query on Exercise 

A- Output Description 

- form showing all data for a given exercise 
even t 

B. Source Data 

- EXERCISE object 

C. Processing Notes 

- EXERCISE object contains USER, WEAPON, BRIEF 
and TARGET object data 

D. Volume 

- five per week 

E . F requenc y 

- daily, as needed 

II. Weekly Exercise Schedule 

A. Output Description 

- ORACLE report form sent to all concerned 

B. Source Data 

- EXERCISE object 

C. Processing Notes 

- EXERCISE object contains BRIEF, USER, WEAPON 
and TARGET objects 

D. Volume 

- 25 per week 

E. Frequency 

- once per week 
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III. Modified Weekly Exercise Schedule 

A. Output Description 

- ORACLE report form sent to all concerned 

- confirmation message on screen 

B. Source Data 

- current Weekly Exercise Schedule 

- EXERCISE object 

- Exercise Type and Event Number keyed by PE 

C. Processing Notes 

- BRIEF, USER, WEAPON and TARGET objects con- 
tained within associated EXERCISE object 

D. Volume 



- 25 per occurrence 

E . Frequency 

- daily, as needed 



EXERCISE OBJECT 
Update Mechanisms 



I. Create Exercise 

A. Input Description 

- list of exercises (from monthly planning 
schedu 1 e ) 

- personnel availability (from A-Base) 

- range availability (from E-Base) 

- TARGET object data (from Project Manager, 
NUWES, and Supporting Commands) 

- USER object data (from Project Manager and 
NUWES) 

- WEAPON object data (from Project Manager and 
Supporting Commands ) 

- BRIEF object data (from Project Manager) 

B. Output Description 

- new EXERCISE object in database 

- new BRIEF object in database 

- new USER object in database 

- new WEAPON object in database 

- new TARGET object in database 

- confirmation message on screen 
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1 1 . 



1 1 1 

IV. 

V. 
VI . 



C. Processing Notes 

- scheduler needs access to A-Base and E-Base 

D. Volume 

- normal two exercises per day, five days per 
week 

E. Frequency 

- once per week 

Modify EXERCISE Data 

A. Input Description 

- changes to monthly planning schedule (from PM, 
NUWES, and Supporting Commands) 

- changes to personnel availability (from ( A- 
Base ) 

- changes to range availability (from E-Base) 

- changes to scheduled exercise event (from PM, 
NUWES and Supporting Commands) 

B. Output Description 

- modified EXERCISE object in database 

- modified BRIEF object in database 

- modified USER object in database 

- modified WEAPON object in database 

- modified TARGET object in database 

- confirmation message on screen 

- change notice sent to all affected 

C. Processing Notes 

- Project Engineer needs access to A-Base and E- 
Base 

D. Volume 

- two per week 

E. Frequency 

- daily, as needed 
Add/Edit BRIEF data to EXERCISE 

- see Update Mechanisms for BRIEF 
Add/Edit USER data to EXERCISE 

- see Update Mechanisms for USER 
Add/Edit WEAPON data to EXERCISE 

- see Update Mechanisms for WEAPON 
Add/Edit TARGET data to EXERCISE 

- see Update Mechanisms for TARGET 
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VII. Delete EXERCISE Event 



A. Input Description 

- scheduled exercise event to be cancelled (from 
PM, NUWES , Supporting Commands, User) 

- EXERCISE object in database 

B. Output Description 

- deletion of EXERCISE object from database 

- deletion of associated BRIEF objects from 
da tabase 

- deletion of associated USER objects from data- 
base 

deletion of associated WEAPON objects from 
database 

- deletion of associated TARGET objects from 
da tabase 

- confirmation message on screen 

- change notice sent to all affected 

C. Volume 

- four exercises per month 

D. Frequency 

- daily, as needed 



EXERCISE OBJECT 
CONTROL MECHANISMS 



I. Provide Password Requirement for Security 



BRIEF OBJECT 
Display Mechanisms 



I. Query on BRIEF 

A. Output Description 

- form showing all data for a given brief 

B. Source Data 

- BRIEF object or EXERCISE object 

- Exercise Type and Event Number keyed by clerk 

C. Processing Notes 

- used by scheduler 



60 



D. Volume 

- three per week 

E. Frequency 

- daily, as needed 

II. Weekly Briefing Report 

A. Output Description 

- ORACLE report form sent to all concerned 

B. Source Data 

- BRIEF object or EXERCISE object 

- Exercise Type and Event Number keyed by clerk 

C. Processing Notes 

- sent to all concerned when weekly schedule 
approved 

D. Volume 

- 25 per week 

E. Frequency 

- once per week 

III. Modified Weekly Briefing Report 

A. Output Description 

- ORACLE report form sent to all concerned 

B. Source Data 

- current Weekly Briefing Report 

- BRIEF object or EXERCISE object 

- Exercise Type and Event Number keyed by clerk 

C. Processing Notes 

- sent to all concerned when changes to schedule 
approved 

D. Volume 

- 25 per week 

E. Frequency 

- daily, as needed 



BRIEF OBJECT 
Update Mechanisms 



I . Create Brief 

A. Input Description 

- list of scheduled exercises (from 0-Base) 
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- list of required briefs for scheduled exercise 
(from Project Manager) 

- room location and availability (from E-Base) 

- briefer availability (from A-Base) 

B. Output Description 

- new BRIEF instance in database 

- new BRIEF data for weekly schedule 

- new BRIEF Weekly Report 

C. Processing Notes 

- scheduler needs access to A-Base and E-Base 

D. Volume 

- minimum two briefs per exercise 

- normal two exercises per day 

E. Frequency 

- once per week per exercise 
I I . Modify BRIEF Data 

A. Input Description 

- changes to scheduled events (from Project 
Manager, NUWES , Users, Supporting Commands) 

- change to room locat ion/avai 1 abi 1 ity (from E- 
Base ) 

- change in briefer availability (from A-Base) 

- change in Brief requirement (from Project 
Manager ) 

B. Output Description 

- modified BRIEF object instance in database 

- modified Weekly Brief Report 

C. Volume 

- one per week 

D. Frequency 

- daily, as needed 
III. Delete BRIEF 

A. Input Description 

- scheduled exercise to be cancelled (from 
Project Manager, NUWES, User) 

- BRIEF objects in database 

B. Output Description 

- deletion of scheduled briefs from database 

- updated Weekly Brief Report 
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- updated room availability in E-Base 
updated briefer availability in A-Base 

C. Processing Notes 

- scheduler needs access to A-Base and E-Base 

D. Volume 

- two exercises per month 

- minimum two briefs per exercise 

E . F requency 

- daily, as needed 

BRIEF OBJECT 
CONTROL MECHANISMS 

I. Provide Password Requirement for Security 

USER OBJECT 
Update Mechanisms 



I . Create USER 

A. Input Description 

- Exercise Type and Event Number (from monthly 
sc hedu 1 e ) 

- name of user to be scheduled for exercise event 
(from PM or NUWES) 

- number of units from a given user to be sched- 
uled for exercise event (from PM, or NUWES) 

- list of authorized users (from database) 

B. Output Description 

- new USER object in database 

C. Processing Notes 

- this function adds USER data to new EXERCISE 

- USER object is created by scheduler as integral 
part of the EXERCISE object 

D. Volume 

- minimum one USER per event 

- normal iO events per week 
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E- Frequency 

- once per week per exercise event 

II. Modify USER Data 

A. Input Description 

- change in number of units of partic ipa ting 
command 

- change in tracking equipment aboard participa- 
ting unit 

B. Output Description 

modified USER object in database 

- modified EXERCISE object in database 

- confirmation message on screen 

- change notification sent to all affected 

C. Processing Notes 

- this process changes USER data and, consequent- 
ly, EXERCISE data for scheduled event 

- Project Engineer makes changes to USER object 
when making changes to associated EXERCISE 
object 

D. Volume 

- one per week 

E. Frequency 

daily, as required 

III. Delete USER 

A. Input Description 

- scheduled user to be deleted from exercise 
event (from PM, NUWES, User Command) 

- EXERCISE object (from database) 

- USER object (embedded in EXERCISE object) 

B. Output Description 

- deletion of indicated user from exercise event 
deletion of ind ic a ted USER object f rom database 

- confirmation message on screen 

- change notice sent to all affected 

C. Processing Notes 

- USER object also deleted with deletion of 
entire exercise event (EXERCISE object) 

WEAPON object (if any) should also be deleted 

D. Volume 

- two per month 
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E. 



Frequency 

daily, as required 



USER OBJECT 
Display Mechanisms 

* USER object is not normally displayed as a separate 
entity. Rather, it is embedded within the associated EXER- 
CISE object. 



USER OBJECT 
CONTROL MECHANISMS 



I. Provide Password Requirement for Security 



WEAPON OBJECT 
Update Mechanisms 



I . Create WEAPON 

A. Input Description 

- Exercise Type, Event Number and Command (from 
monthly schedule) 

- weapon scheduled for exercise event (from PM) 
list of authorized weapons (from database) 

B. Output Description 

- new WEAPON object in database 

C. Processing Notes 

- WEAPON object is created by scheduler as an 
integral part when the USER object is created 

D. Volume 

- normal two WEAPON objects per user 

- minimum one user per event 

- normal 10 events per week 

E. Frequency 

- minimum once per week per exercise event 
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1 1 . 



III. 



Modify WEAPON Data 

A. Input Description 

- Exercise Type, Event Number and Command 

- change in WEAPON data (from PM or Supporting 
Command ) 

- change in USER data (from PM or NUWES ) 

B. Output Description 

- modified WEAPON object in database 

- modified USER object in database 

- confirmation message on screen 

- change notification sent to all affected 

C. Processing Notes 

- this process changes WEAPON data and, conse- 
quently, USER object data for a given scheduled 
even t 

- Project Engineer makes changes to USER object 
when making changes to associated WEAPON object 

D. Volume 

- one per week 

E. Frequency 

- daily, as required 
Delete WEAPON 



A. Input Description 

- Exercise Type, Event Number, Command Name 

- weapon to be deleted (Mk) 

- USER object (from database) 

WEAPON object (embedded within USER object) 

B. Output Description 

- deletion of indicated weapon(s) from exercise 
even t 

- deletion of indicated WEAPON object from data- 
base 

- confirmation message on screen 

- change notification sent to all affected 

C. Processing Notes 

- WEAPON object is also deleted with deletion of 
entire exercise event (EXERCISE object) and 
with the deletion of a user (USER object) from 
an exercise event 
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D. Volume 

- two per month 

E . Frequency 

- daily, as required 



WEAPON OBJECT 
Display Mechanisms 



* WEAPON object is not normally displayed as a sepa- 
rate entity. Rather, it is embedded within its associated 
USER object. 



WEAPON OBJECT 
CONTROL MECHANISMS 



I. Provide Password Requirement for Security 



TARGET OBJECT 
Update Mechanisms 



I . Create TARGET 

A. Input Description 

- Exercise Type and Event Number (from monthly 
sc hedu 1 e ) 

- target to be scheduled for exercise event 
(from PM or NUWES ) 

- list of targets (from database) 

B. Output Description 

new TARGET object in database 

C. Processing Notes 

TARGET object is created by scheduler as an 
integral part when the EXERCISE object is 
c rea ted 

D. Volume 

minimum one TARGET per event 

- normal 10 events per week 
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E. Frequency 

- minimum once per week per exercise event 

II. Modify TARGET Data 

A. Input Description 

- Exercise Type and Event Number 

change in Target data (from PM or NUWES) 

B. Output Description 

- modified TARGET object in database 

- modified EXERCISE object in database 

- confirmation message on screen 

change notification sent to all affected 

C. Processing Notes 

- this process changes TARGET data and, conse- 
quently, EXERCISE object data for a given 
scheduled event 

Project Engineer makes changes to EXERCISE 
object when making changes to associated 
TARGET object 

D. Volume 

- one per week 

E . F requency 

- daily, as required 

III. Delete TARGET 

A. Input Description 

- Exercise Type and Event Number 

target to be deleted (from PM or NUWES) 
EXERCISE object (from database) 

- TARGET object (embedded within EXERCISE ob- 
ject) 

B. Output Description 

- deletion of indicated target from exercise 
even t 

- deletion of indicated TARGET object from data- 
base 

- confirmation message on screen 

change notification sent to all affected 

C. Processing Notes 

- TARGET object is also deleted with deletion of 
entire exercise event (EXERCISE object) 
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D. Volume 

~ two per month 

E. Frequency 

- daily, as required 



TARGET OBJECT 
Display Mechanisms 

* TARGET object is not normally displayed as a sepa- 
rate entity. Rather, it is embedded within its associated 
EXERCISE object. 



TARGET OBJECT 
CONTROL MECHANISMS 



I. Provide Password Requirement for Security 



B. Results Application 

OPERATIONS ANALYST APPLICATION 
DISPLAY MECHANISMS 



I. Monthly/Quarter ly Reports 

A. Output Description 

- tables for monthly and quarterly reports on 
sc reen 

- tables for monthly and quarterly reports 

B. Source Data 

- RESULTS object 

- user input time period for tables 

- tables desired 

C. Processing Notes 

- use menus to choose which table to print and 
time period covered 

D. Volume 

- two per month 
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E. Frequency 

- monthly 
I I . TRIMS Data 

A. Output Description 

- ASCII file for import into DB3 + 

- screen showing TRIMS data 

B. Source Data 

- RESULTS object 

C. Processing Notes 

- ensure all exercise entered into O-Base before 
runn ing 

D. Volume 

- once per month 

E. Frequency 

- monthly 

III. Community Reports 

A. Output Description 

- screen with summary data presented 

- paper report of community data 

B. Source Data 

- RESULTS object 

C. Processing Notes 

- user selects time period and community to be 
summar i zed 

D. Volume 

- five per quarter 

E . F requency 

- quarterly 

OPERATIONS ANALYST APPLICATION 
CONTROL MECHANISMS 



I. Provide Password Requirement for Security. 
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ENTRY CLERK APPLICATION 
PLATFORM Object 
Update Mechanisms 



I . Create PLATFORM 

A. Input Description 

- Exercise Summary 

- EXERCISE object 

B. Output Description 

- Exercise Summary neat 

- new instance of PLATFORM 

- confirmation message 

C. Processing Notes 

- Platform must correspond to event in RESULT 

D. Volume 

- two per event 

E. Frequency 

- once per day 
I I . Modify PLATFORM 

A. Input Description 

PLATFORM object instance from database 

- required changes 

B. Output Description 

- modified objects 

- updated Event Summary neat 

C. Processing Notes 

- any changes of the data in PLATFORM can cause 
instances to be deleted or changed from ATTACK 
ob j ec t 

D. Volume 

- two per week 

E. Frequency 

- weekly 

III. Add/Edit ATTACK to PLATFORM 

A. See Update Mechanisms for ATTACK 
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PLATFORM OBJECT 
Display Mechanisms 



I . Query on PLATFORM 

II. Output Description 

- form showing all data for a given event 

- same form as for input of data 

A. Source Data 

- PLATFORM object 

B. Processing Notes 

- all data in different objects must be joined 
toge t he r 

- on querying a multi-valued field must show or 
indicate other occurrences 

- on querying a non-key field must indicate other 
occur renc es 

C. Volume 

- four per day 

D. Frequency 

- daily 

III. Exercise Summary neat 

A. Output Description 

- computer printed exercise summary 

- format to be similar to hand written exercise 
summary 

B. Source Data 

- PLATFORM object 

C. Processing Notes 

- used by Program Engineer to check data and 
paper record 

- for each new instance and modified instance one 
is made 

D. Volume 

- 12 per week 

E . F requency 

- daily 
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PLATFORM OBJECT 
Control Meehan isms 



I. Provide Password Requirement for Security. 

II. In query mode no changes can be made and is available 
only to PE, and OA . 



ENTRY CLERK APPLICATION 
ATTACK Object 
Update Mechanisms 

I. Create ATTACK Object 

A. Input Description 

- Exercise Summary 

- EXERCISE object 

B. Output Description 

- Exercise Summary neat 

- new instance of ATTACK 

- confirmation message 

C. Processing Notes 

- an ATTACK must be associated with a PLATFORM 

D. Volume 

- four per event 

E. Frequency 

- once per day 
I I . Modify ATTACK 

A. Input Description 

- ATTACK object instance from database 

- required changes 

B. Output Description 

- modified objects 

- updated Event Summary neat 

C. Processing Notes 

any changes of the data in ATTACK can cause 
instances to be deleted from or changed in LOST 
Object and/or WEAPON RESULTS Object. 

D. Volume 

- two per week 
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E. Frequency 
- weekly 

III. Add/Edit LOST to ATTACK 

A. See Update Mechanisms for LOST Object 

IV. Add/Edit WEAPON RESULTS to ATTACK 

A. See Update Mechanisms for WEAPON RESULTS 



ATTACK Object 
Display Mechanisms 



I. Query on ATTACK 

A. Output Description 

- form showing all data for a given event 

- same form as for input of data 

B. Source Data 

- ATTACK object 

C. Processing Notes 

- all data in different objects must be joined 
together 

- on querying a multi-valued field must show or 
indicate other occurrences 

- on querying a non-key field must indicate other 
occur rences 

D. Volume 

- four per day 

E. Frequency 

- daily 

II. Exercise Summary neat 

A. Output Description 

- computer printed Exercise Summary 

- format to be similar to hand written Exercise 
Summary 

B. Source Data 

- ATTACK object 

C. Processing Notes 

- used by Program Engineer to check data and 
paper record 
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- for each new instance and modified instance one 
is made 

D. Volume 

- 12 per week 

E . Frequency 

- daily 



ATTACK OBJECT 
Control Mechanisms 

I. Provide Password Requirement for Security. 

II. In query mode no changes can be made and is available 
only to PE and OA . 



ENTRY CLERK APPLICATION 
WEAPON RESULTS Object 
Update Mechanisms 

I. Create WEAPON RESULTS Object 

A. Input Description 

- Exercise Summary 
EXERCISE object 

B. Output Description 

- Exercise Summary neat 

- new instance of WEAPON RESULTS 

- confirmation message 

C. Processing Notes 

- a WEAPON must correspond to a TOF in ATTACK 

- if a Platform performs a simulated attack no 
weapon results is created 

D. Volume 

- three per event 

E . F requenc y 

- once per day 
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II. Modify WEAPON RESULTS 

A. Input Description 

- WEAPON RESULTS object instance from database 

- required changes 

B. Output Description 

- modified objects 

- updated Exercise Summary neat 

C. Processing Notes 

- any changes of the data in WEAPON RESULTS can 
cause instances to be deleted from or changed 
in LOST object 

D. Volume 

- two per week 

E . F requency 

- weekly 

III. Add/Edit LOST to WEAPON RESULTS 

A. See Update Mechanisms for LOST Object 

WEAPON RESULTS OBJECT 
Display Mechanisms 

I . Query on WEAPON RESULTS 

A. Output Description 

- form showing all data for a given event 

- same form as for input of data 

B. Source Data 

- WEAPON RESULTS object 

C. Processing Notes 

- all data in different objects must be joined 
together 

- on querying a multi-valued field must show or 
indicate other occurrences 

- on querying a non-key field must indicate other 
occur rences 

D. Volume 

- four per day 

E. Frequency 

- daily 
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II. Exercise Summary neat 

A. Output Description 

- computer printed Exercise Summary 

- format to be similar to hand written Exercise 
Summary 

B. Source Data 

- WEAPON RESULTS object 

C. Processing Notes 

- used by Program Engineer to check data and 
paper record 

- for each new instance and modified instance one 
is made 

D. Volume 

- 12 per week 

E. Frequency 

- daily 



WEAPON RESULTS OBJECT 
Control Mechanisms 



I. Provide Password Requirement for Security. 

II. In query mode no changes can be made and is available 
only to PE and OA . 



ENTRY CLERK APPLICATION 
TARGET RESULTS Object 
Update Mechanisms 



I. Create TARGET RESULTS Object 

A. Input Description 

- Exercise Summary 

- EXERCISE object 

B. Output Description 

- Exercise Summary neat 

- new instance of TARGET RESULTS 

- confirmation message 



77 



C. Processing Notes 

- a target must correspond to event in RESULT 

D. Volume 

one per event 

E. Frequency 

- once per day 

II. Modify TARGET RESULTS 

A. Input Description 

- TARGET RESULTS object instance from database 

- required changes 

B. Output Description 

- modified objects 

C. Updated Exercise Summary neat 

D. Processing Notes 

- any changes of the data in TARGET RESULTS can 
cause instances to be deleted from or changed 
in LOST object 

E. Volume 

- two per week 

F. Frequency 

- week 1 y 

III. Add/Edit LOST to TARGET RESULTS 

A. See Update Mechanisms for LOST 

TARGET RESULTS OBJECT 
Display Mechanisms 

I . Query on TARGET RESULTS 

A. Output Description 

- form showing all data for a given event 

- same form as for input of data 

B. Source Data 

- TARGET RESULTS object 

C. Processing Notes 

- all data in different objects must be joined 
together 

- on querying a multi-valued field must show or 
indicate other occurrences 
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- on querying a non-key field must indicate other 
occur rences 

D. Volume 

- four per day 

E. Frequency 

- daily 

II- Exercise Summary neat 
A. Output Description 

- computer printed Exercise Summary 

- format to be similar to hand written Exercise 
Summary 

B- Source Data 

- TARGET RESULTS object 
C. Processing Notes 

- used by Program Engineer to check data and 
paper record 

- for each new instance and modified instance one 
is made 

D- Volume 

- 12 per week 
E. Frequency 

- daily 



TARGET RESULTS OBJECT 
Control Mechanisms 



I. Provide Password Requirement for Security. 

II. In query mode no changes can be made and is available 
only to PE and OA . 



ENTRY CLERK APPLICATION 
LOST Object 
Update Mechanisms 



I . Create LOST 

A. Input Description 

- Exercise Summary 

- EXERCISE object 
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B. Output Description 

Exercise Summary neat 

- new instance of LOST 

- confirmation message 

C. Processing Notes 

- a LOST must correspond to a MK and Serial in 
WEAPON RESULTS or TARGET RESULTS 

D. Volume 

- four per year 

E. Frequency 

- once per quarter 
I I . Modify LOST 

A. Input Description 

- LOST object instance from database 

- required changes 

B. Output Description 

- modified objects 

- updated event summary neat 

C. Processing Notes 

- any changes of the data in WEAPON RESULTS or 
TARGET RESULTS can cause instances to be de- 
leted or changed from LOST object 

D. Volume 

- four per year 

E. Frequency 

- semi-annually 

LOST OBJECT 
Display Mechanisms 

I . Query on LOST 

A. Output Description 

- form showing all data for a given event 

- same form as for input of data 

B. Source Data 

- LOST object 

C. Processing Notes 

- all data in different objects must be joined 
together 
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- on querying a multi-valued field must show or 
indicate other occurrences 

- on querying a non-key field must indicate other 
occur rences 

D. Volume 

- two per month 

E. Frequency 

- monthly 

II. Exercise Summary neat 

A. Output Description 

- computer printed exercise summary 

- format to be similar to hand written exercise 
summary 

B. Source Data 

- LOST object 

C. Processing Notes 

- used by Program Engineer to check data and 
paper record 

- for each new instance and modified instance one 
is made 

D. Volume 

- 12 per week 

E. Frequency 

- daily 



LOST OBJECT 
Control Mechanisms 



1 . 


Provide Password 


Requi remen t 


for 


Secur i ty 


1 1 


. In query mode no 


changes can 


be 


made and 




only to PE, and 


OA. 
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APPENDIX F 



RELATION DIAGRAMS 



A. Schedule Application 



EXERCISE 
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b-e 



B. Results Application 
RESULT 
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APPENDIX G 



LOGICAL MENU STRUCTURE 
A. SCHEDULE APPLICATION 
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B 



RESULTS APPLICATION 
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APPENDIX H 



ORACLE TABLES 



A. APPLICATION TABLES 



EXERCISE TABLE 



Name 


Nu 11? Type 


EXER 


NOT NULL CHAR ( 4 ) 


EVENT 


NOT NULL NUMBER (5 


EXDESC 


CHAR ( 12 ) 


SST ART 


CHAR ( 14 ) 


SSTQP 


CHAR ( 14) 


MST ART 


CHAR ( 14 ) 


MSTQP 


CHAR ( 14 ) 


□PAREA 


CHAR ( 6 ) 


TRACKTYPE 


CHAR ( 1 ) 


PROJENG 


CHAR ( 10) 


DPCON 


CHAR ( 10) 


□PANAL 


CHAR ( 10) 


SAFEQFF 


CHAR ( 10) 


TPRIREC 


CHAR (7) 


TSECREC 


CHAR ( 7 ) 


WPRIREC 


CHAR (7) 


WSECREC 


CHAR ( 7 ) 


HAULBACK 


CHAR (7) 


GRNREQ 


CHAR ( 1 ) 


GRNSENT 


CHAR ( 1 ) 


SUBRLX 


CHAR ( 1 ) 


AIRSPACE 


CHAR ( 5 ) 


COMM 


CHAR ( 3 ) 


EXCLUS 


CHAR ( 1 ) 
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SCH COMMENT TABLE 



Name 



Null? Type 



EXER 


NOT 


NULL 


CHAR ( 4 ) 


EVENT 


NOT 


NULL 


NUMBER ( 5) 


LINENO 


NOT 


NULL 


NUMBER ( 3 ) 


COMMENTS 






CHAR (75) 



BRIEF TABLE 

Name Null? Type 



EXER 

EVENT 

TITLE 

TIME 

LOCATION 

BRIEFER 



NOT NULL 
NOT NULL 
NOT NULL 



CHAR ( 4 ) 
NUMBER ( 5 ) 
CHAR (20) 
CHAR ( 14 ) 
CHAR (20) 
CHAR ( 10 ) 



TARGET TABLE 



Name Nu 11? Type 



EXER 


NOT 


NULL 


CHAR ( 4 ) 


EVENT 


NOT 


NULL 


NUMBER ( 5 ) 


TGTDESIG 


NOT 


NULL 


CHAR ( 8 ) 


GEOMETRY 






CHAR ( 4 ) 


ACOUSTICS 






CHAR ( 1 ) 


TPINGER 






CHAR ( 4 ) 


LNCHVEH 






CHAR ( 8 ) 
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USER TABLE 



Name Null? Type 



EXER 


NOT 


NULL 


CHAR (4 


EVENT 


NOT 


NULL 


NUMBER 


COMMAND 


NOT 


NULL 


CHAR (8 


UNUMBER 






NUMBER 


TRANSPONDER 






CHAR (4 


UPINGER 






CHAR (4 





WEAPON TABLE 






Name 


Null 


7 


Type 


EXER 


NOT 


NULL 


CHAR ( 4 


EVENT 


NOT 


NULL 


NUMBER 


MK 


NOT 


NULL 


CHAR ( 5 


COMMAND 


NOT 


NULL 


CHAR (8 


SNUMBER 






NUMBER 


WPINGER 






CHAR ( 4 



RESULT TABLE 



Name 


Null? 


Type 


EXER 


NOT NULL 


CHAR ( 4 ) 


EVENT 


NOT NULL 


NUMBER ( 5 ) 


EXDESC 




CHAR( 12) 


COMEX 




CHAR( 14 ) 


FINEX 




CHAR ( 14 ) 


SST ART 




CHAR ( 14) 


SSTOP 




CHAR ( 14) 


OP AREA 




CHAR ( 6 ) 


VISIBLE 




NUMBER (2) 
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SEASTATE 



EXCOMMENTS TABLE 



NUMBER ( 1 ) 



Name 




Null? 


Type 


EXER 




NOT NULL 


CHAR ( 4 ) 


EVENT 




NOT NULL 


NUMBER ( 5) 


LINENO 






NUMBER ( 3 ) 


COMMENTS 


CLASSCMTS 


TABLE 


CHAR (75) 


Name 




Null? 


Type 


EXER 




NOT NULL 


CHAR ( 4 ) 


EVENT 




NOT NULL 


NUMBER ( 5) 


LINENO 






NUMBER ( 3 ) 


COMMENTS 


SUPPORT 


TABLE 


CHAR ( 75 ) 


Name 




Null? 


Type 


EXER 




NOT NULL 


CHAR ( 4 ) 


EVENT 




NOT NULL 


NUMBER ( 5 ) 


SPLATFORM 






CHAR ( 8 ) 


SSIDENO 






CHAR ( 7 ) 


USED 






CHAR ( 1 ) 



90 



CANCEL TABLE 



Name 



Null? Type 



EXER 

EVENT 

CANCEL 

HOURLOST 

CANCELTIME 



NOT NULL CHAR ( 4 ) 

NOT NULL NUMBER* 5) 
CHAR ( 25 ) 
NUMBER* 2, 1 ) 
CHAR* 14 ) 



PLATFORM TABLE 



Name 


Null? 


Type 


EXER 


NOT NULL 


CHAR (4 


EVENT 


NOT NULL 


NUMBER 


COMMAND 




CHAR (8 


SIDENO 




CHAR (7 


SHOWED 




CHAR* 1 


TRACKQP 




NUMBER 


LOFAR 




NUMBER 


DIFAR 




NUMBER 


DICAS 




NUMBER 


VLAD 




NUMBER 





SCHWEP TABLE 




Name 


Null? 


Type 


EXER 


NOT NULL 


CHAR (4 


EVENT 


NOT NULL 


NUMBER 


COMMAND 




CHAR ( B 


SIDENO 




CHAR ( 7 


WEAPON 




CHAR (5 


SNUMBER 




NUMBER 
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NODROP 


ATTACK TABLE 




CHAR ( 1 ) 


Name 


Null? 


Type 


EXER 


NOT 


NULL 


CHAR ( 4 ) 


EVENT 


NOT 


NULL 


NUMBER ( 5 


TOP 






CHAR ( 14) 


COMMAND 






CHAR (8) 


SIDENO 






CHAR ( 7 ) 


STARTOP 






CHAR ( 14 ) 


TGTCOURSE 






NUMBER ( 3 


TGTBY 






NUMBER (3 


TGTSPEED 






NUMBER (2 


TGTRANGE 






NUMBER ( 5 


TGTDEPTH 






NUMBER (4 


TGTMANT I ME 






NUMBER (2 


TGTMANCOURSE 






NUMBER (3 


TGTMANSPEED 






NUMBER ( 2 


SBY 






NUMBER ( 3 


SCOURSE 






NUMBER (3 


SSPEED 






NUMBER ( 2 


SRANGE 






NUMBER ( 5 


HEADTOF 






NUMBER ( 3 


SPEEDTOF 






NUMBER (3 


ALTITUDE 






NUMBER ( 5 


MODECODE 






CHAR ( 6 ) 


SONARSET 






CHAR ( 7 ) 


CONTACT 






CHAR ( 12) 


DELIVERY 






CHAR ( 5 ) 


SPLASHBY 






NUMBER (3 


SPLASHRH 






NUMBER ( 5 


ACQUIRED 






CHAR ( 1 ) 


ATTACKEVAL 






CHAR ( 10 ) 


SEARCHDEPTH 






NUMBER ( 4 


DOPPLER 






CHAR ( 1 ) 


PH 






NUMBER ( 1 
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ATTCOMMENTS TABLE 



Name 



Nu 11? Type 



TOF 

LINENO 

COMMENTS 



NOT NULL CHAR (14) 
NUMBER ( 3 ) 
CHAR (75) 



WEAPONR TABLE 



Name Null? Type 



TOF 

MK 

SERIAL 

MOD 

TORPPERF 

SEARCHT 

WEPREC 

RECVEH 

RECTIME 

BBVEH 

TRACKQW 



CHAR ( 14 ) 
CHAR ( 5) 
CHAR (7) 
CHAR ( 5 ) 
CHAR (20) 
NUMBER (3) 
CHAR ( 1 ) 
CHAR ( 8 ) 
NUMBER ( 2 ) 
CHAR (8) 
NUMBER ( 3 ) 
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LOST TABLE 



Name 


Nu 11? Type 


Mk 


CHAR ( 5 ) 


SERIAL 


CHAR ( 7 ) 


TOF 


CHAR ( 14 ) 


EXER 


CHAR ( 4 ) 


EVENT 


NUMBER ( 5 ) 


NOD 


CHAR ( 5) 


LAT 


CHAR ( 10) 


LONGITUDE 


CHAR ( 10 ) 


IMPLOSION 


NUMBER ( 4 ) 


WDEPTH 


NUMBER ( 5 ) 


T IMELOSS 


CHAR ( 14 ) 


FROMBLOCK 


CHAR ( 1 ) 



TARGE1R TABLE 



Name 


Nu 11? Type 


EXER 


CHAR ( 4 ) 


EVENT 


NUMBER! 5) 


TGTDESI6 


CHAR( 8) 


SERIAL 


CHAR! 7) 


TGTPERF 


CHAR (20) 


GEOMETRY 


CHAR! 4 ) 


TOF 


CHAR ( 14 ) 


TGTREC 


CHAR ( 1 ) 


RECVEH 


CHAR (8) 


DB 


NUMBER (3) 


FREQ 


CHAR! 2) 


TRACKQT 


NUMBER! 3) 


MOD 


CHAR! 5) 
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B. LOOK-UP TABLES 





CANCELLOOKUP 


Name 


Nu 11? T y pe 


CANCELLOOKUP 


CHAR (25) 



CANCEL (Legal Values) 

ASSET AVAILABILITY 
FOULED RANGE 
INSTRUMENTATION 
WEATHER 

NO AIR TRACKING 
NO SHOW 





CONTACTLOOKUP 


Name 


Null? Type 


CONTACT 


CHAR ( 12 ) 



CONTACT (Legal 


Va 1 ues ) 


NAD 


SURFACT 


DIFAR 


IR 


DICASS 


VECTAC 


RANGE ONLY 


SPHERICAL 


LOFAR 


HULL 


DIPPER 

SURFPASS 


TOWED ARRAY 
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DEL I VERYLOOKUP 



Name 



Null? 



DELI V 



DELIVERY (Legal Values) 



SVTT 

RTT 

HOVER 

FLYIN 

TT 

ASROC 



Name 



EVALLOOKUP 

Null? 



EVAL 



EVAL (Legal Values) 



HIT 

PROB HIT 
PROB MISS 
HISS 
UNKNOWN 



Type 



CHAR ( 5 ) 



Type 



CHAR ( 10) 
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Name 



LINENUliBER 



Type 



Null? 



TABLENAME 

EXER 

EVENT 

LINENO 



TABLENAME EXER EVENT LINENO 



SCH_COMMENT 
SCH_COMMENT 
SCH_COMMENT 
SCH COMMENT 



Name 



A601 


89004 


1 


A601 


89005 


1 


A612 


88082 


7 


S610 


89001 


1 



PERFLOOKUP 

Null? 



PERF 



PERF (Legal Values) 



NORMAL RUN 

ERRATIC RUN 

DID NOT RUN 

SANK AT LAUNCH POINT 

SANK AT END OF RUN 

DAMAGED 

SEE COMMENTS 



CHAR ( 15) 
CHAR ( 4 ) 
CHAR ( 5 ) 
NUMBER ( 3 ) 



Type 



CHAR (20) 
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Name 



RECOVLOOKUP 

Null? 



RECOV 



RECO (Legal Values) 



TWR 

HC-1 



SONARLOOKUP 



Name 



Null? 



SONAR 



SONAR (Legal Values) 



ACTIVE 

PASSIVE 

COMBO 

ACTPASS 



Type 



CHAR ( 4 ) 



Type 



CHAR ( 7 ) 
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APPENDIX I 



VARIABLE ASSOCIATIONS 



EXERCISE OBJECT 

Descriptive Name Domain Name 



Exercise Type 
Event Number 
Exercise Description 
Schedule Start Time 
Schedule Stop Time 
MOCS Start Time 
MOCS Stop Time 
Operational Area 
Exclusive Use 
Primary Target 

Recovery Vehicle 
Secondary Target 

Recovery Vehicle 
Primary Weapon 

Recovery Vehicle 
Secondary Weapon 

Recovery Vehicle 
Weapon Haulback 
Vehic 1 e 
Tracking Type 
Project Engineer 
Operation Control ler 
Operation Analyst 
Safety Officer 
Green Required 
Green Sent 

Submarine Relaxation 
Message 
Air Space 
Commun ications 
Commen ts 



Exer 
Even t 
Exdesc 

T ime-Sc hstar t 
T ime-Sc hstop 
Time-MOCS Start 
Time-MOCS Stop 
Oparea 
Exc 1 usi ve 

Recovery-Pr i 

Recovery-Sec 

Recovery-Pr i 

Recovery-Sec 

Recovery-Hau 1 bac k 
Tracking Type 
Personne 1 -Pe 
Personne 1 -Oc 
Personne 1 -Oa 
Personne 1 —So 
Message-Req 
Message-Sent 

Message-Sub 
Air Space 
Communications 
Comments 
MV 



BRIEF: BRIEF object; 

USERS: USER object; 



TARGET: TARGET object; MV 

RESULTS: RESULTS object 



Variable Name 



EXER 

EVENT 

EXDESC 

SSTART 

SSTOP 

MSTART 

MSTOP 

OPAREA 

EXCLUS 

TPRIREC 

TSECREC 

WPRIREC 

WSECREC 

HAULBACK 

TRACKTYPE 

PROJENG 

OPCON 

OPANAL 

SAFEOFF 

GRNREQ 

GRNSENT 

SUBRLX 

AIRSPACE 

COMM 

COMMENTS 
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BRIEF OBJECT 



Descriptive Name Domain Name Variable Name 



Brief Title 
Brief T ime 
Location 
Br ief er 


Brief Title 
T ime-Brief 
Loca tion 
Personnel -Brief 


TITLE 

TIME 

LOCATION 

BRIEFER 




USERS OBJECT 




Descriptive Name 


Domain Name 


Variable Name 


Exercise Type 

Event Number 

Command Name 

Number of Units 

EATS Transponder 

Pinger Channel 

WEAPON: WEAPON object 


Exer 
Even t 
Command 
Number-U 
T ransponder 
Pinger-U 
; MV 


EXER 

EVENT 

COMMAND 

UNUMBER 

TRANSPONDER 

UPINGER 




TARGET OBJECT 




Descriptive Name 


Domain Name 


Variable Name 


Exercise Type 
Event Number 
Target Designation 
Geome t ry 
Acoustics 
Pinger 

Launch Vehicle 


Exer 
Even t 

Target Design a t ion 
Geometry Code 
Acoustics 
P inger-T 
Launc h 


EXER 

EVENT 

TGTDESIG 

GEOMETRY 

ACOUSTICS 

TPINGER 

LNCHVEH 




WEAPON OBJECT 




Descriptive Name 


Domain Name 


Variable Name 


Mk 

Command Name 
Number Scheduled 
Pinger 


Mk 

Command 

Number-S 

Pinger-W 


MK 

COMMAND 

SNUMBER 

WRINGER 
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RESULTS OBJECT 



Descriptive Name 



Domain Name 



Variable Name 



Exercise Type 


Exer 


EXER 


Event Number 


Event 


EVENT 


Exercise Description 


Exdesc 


EXDESC 


Exercise Attainment 


Exa ttain 


EXATTAIN 


Comex 


T ime-C 


COMEX 


Finex 


T ime-F 


FINEX 


Scheduled Start Time 


T ime-Sc hstar t 


SSTART 


Scheduled Stop Time 


T ime-Schstop 


SSTOP 


Operational Area 


Oparea 


OPAREA 


Visibil ity 


Visible 


VISIBLE 


Sea State 


Seasta te 


SEASTATE 


Reason Canceled MV 


Cancel ed 


CANCEL 


Hours Lost MV 


Hours 


HOURLOST 


Cancel Start Time MV 


T ime-Cance 1 


CANCELTIME 


Support Platform MV 


Command 


SPLATFORM 


Support Side Number MV 


Sidenumber 


SSIDENO 


Support Used MV 


Used 


USED 


Classified Commen ts 


Commen ts 


COMMENTS 


Unc lassified Commen ts 


Commen ts 


COMMENTS 



PLATFORM; PLATFORM object; MV 

TARGET RESULTS; TARGET RESULTS object; MV 



PLATFORM OBJECT 

Descriptive Name Domain Name Variable Name 



Exercise Type 


Exer 


EXER 


Event Number 


Event 


EVENT 


Command Name 


Command 


COMMAND 


Side Number 


Sidenumber 


SIDENO 


Showed Up 


Showed 


SHOWED 


Track Quality 


T rack Qua 1 i ty 


TRACKQP 


Lof ar 


Sonobuoy no. 


LOFAR 


Di f ar 


Sonobuoy no. 


DIFAR 


Dicass 


Sonobuoy no. 


DICAS 


Vlad 


Sonobuoy no. 


VLAD 


Weapon Assigned MV 


Mk 


WEAPON 


Number of Weapons 
Scheduled MV 


Number-S 


SNUMBER 


No Drop MV 


Nodrop 


NODROP 


ATTACK; ATTACK object; 


MV 
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TARGET RESULTS OBJECT 



Descriptive Name 


Domain Name 


Variable Name 


Exercise Type 


Exer 


EXER 


Event Number 


Even t 


EVENT 


Target Designation 


Target Designation 


TGTDESIG 


Mod 


Mod 


MOD 


Serial Number 


Serial Number 


SERIAL 


Target Performance 


Target Performance 


TGTPERF 


Geometry 


Geometry Code 


GEOMETRY 


Launch Time 


T ime-L 


TOF 


Target Recovered 


Recovered 


TGTREC 


Recovery Vehicle 


Recovery 


RECVEH 


Sound Level 


Sound 


DB 


F requency 


F requency 


FREQ 


Track Quality 
LOST; LOST object 


Track Quality 


TRACKQT 



Descriptive Name 


WEAPON RESULTS OBJECT 
Domain Name 


Variable Name 


Time of Fire 


TOF 


TOF 


Mk 


Mk 


MK 


Mod 


Mod 


MOD 


Serial Number 


Serial Number 


SERIAL 


Torpedo Performance 


Tor pper f 


TORPPERF 


Search T ime 


Sea rc h-Seconds 


SEARCH 


Weapon Recovered 


Recovered 


WEPREC 


Recovery Vehicle 


Recovery 


RECVEH 


Recovery Time 


Minutes -Recover 


RECTIME 


Bring Back Vehicle 


Recovery 


BBVEH 


Track Quality 
LOST; LOST object 


Track Quality 


TRACKQW 



Descriptive Name 


LOST OBJECT 
Domain Name 


Variable Name 


Mk 


Mk 


MK 


Mod 


Mod 


MOD 


Serial Number 


Serial Number 


SERIAL 


T ime Lost 


T ime-Los t 


TIMELOST 


Latitude 


La t 


LAT 


Long i tude 


Long 


LONGITUDE 


I mp 1 os ion 


Depth- Imp 


IMPLOSION 


Water Depth 


Depth-Water 


WDEPTH 
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ATTACK OBJECT 



Descriptive Name 



Domain Name 



Variable Name 



Time of Fire 


T ime-Tof 


TOF 


Command Name 


Command 


COMMAND 


Side Number 


Sidenumber 


SIDENO 


Start Op 


T i me-S tar t- time 


STARTOP 


Actual Target Course 


Compass-Tc 


TGTCOURSE 


Actual Target Bearing 


Compass-Tb 


TGTBY 


Actual Target Speed 


Kts-T s 


TGTSPEED 


Actual Target Range 


Range-T 


TGTRANGE 


Actual Target Depth 


Depth-T 


TGTDEPTH 


Target Maneuver Time 
Target Maneuver 


Minu tes-Maneu ver 


TGTMANT I ME 


Course 

Target Maneuver 


Compass-Tm 


TGTMANCOURSE 


Speed 


Kts-Tm 


TGTMANSPEED 


Target Doppler 


Dopp 1 er 


TGTDOPLER 


Solution Bearing 


Compass-Sb 


SBY 


Solution Course 


Compass-Sc 


SCOURSE 


Solution Speed 


Kts-S 


SSPEED 


Solution Range 


Range-S 


SRANGE 


Heading at TOF 


Compass-Heading 


HEADTOF 


Speed at TOF 


Speed 


SPEEDTOF 


Altitude 


Height 


ALTITUDE 


Mode 


Modecode 


MODECODE 


Sonar Setting 


Sonar 


SONARSET 


Contact Type 


Contact Code 


CONTACT 


Delivery Method 


Delivery Code 


DELIVERY 


Bearing to Splash Point 


Compass-Sp 1 ashpt 


SPLASHBY 


Range to Splash Point 


Range-Splashpt 


SPLASHRH 


Acquired 


Acquired 


ACQUIRED 


Eval of Attack 


Eval 


ATTACKEVAL 


Search Depth 


Dept h-S 


SEARCHDEPTH 


Comments MV 


Comments 


COMMENTS 


Line Number MV 

WEAPON RESULTS; WEAPON 


Linenumber 
RESULTS object; 


LINENO 
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APPENDIX J 



SCREEN DESIGNS 
SCHEDULE APPLICATION 



♦ - - 



INPUT NEM EVENT DATA 

♦ + ♦ 

! EXERCISE TYPE: EVENT NUMBER: ! 

! EXERCISE DESCRIPTION: J 



+ + 

EXERCISE TIMES: 



SCHEDULED START: 
MOCS MAN-UP : 



SCHEDULED FINISH: 
MOCS SHUT-DOWN: 



EXERCISE PERSONNEL: 



PROJECT ENGINEER: 
OPERATION CONTROL: 
OPERATION ANALYST: 
SAFETY OFFICER: 



OPf RATIONAL ARIA AlillNIDt 



EXCLUSIVE USE?) 



+ + 



± __ - 


MISCELLANEOUS EVENT DATA 




1 

1 


T 


! EXERCISE TYPE: EVENT NUMBER: 


X 

1 


t 

1 

1 




TRACKING TYPE: _ 




1 

t 

1 

1 


1 --, 






1 


T 


EVENT MESSAGES: 




1 

1 

1 




GREEN REQUIRED?: _ GREEN SENT?: _ 




1 

1 

1 

1 


± 


SUBMARINE RELAXATION HESSA6E REQUIRED?: _ 




1 

1 

1 

1 

1 


T 


AIR SPACE RESTRICTIONS: 




1 

1 

1 




COMMUNICATIONS: 




1 

1 

1 
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> 4 * 



! EVENT SUPPORT VEHICLES 

*--♦ - +--♦ 

! ! EXERCISE TYPE: EVENT NUH8ER: J ! 

! + + | 

i t 

i TARBET SUPPORT VEHICLES: j 

! PRIMARY TARGET RECOVERY: \ 

I I 

! SECONDARY TAR6ET RECOVERY: ! 

I I 

t I 

I I 

! WEAPON SUPPORT VEHICLES: ! 



! PRIMARY WEAPON RECOVERY: | 

I I 

I SECONDARY WEAPON RECOVERY: ! 

I I 

; WEAPON HAULBACK: | 

+- ♦ 



+— 



INPUT EXERCISE BRIEF DATA 





EXERCISE TYPE: 

+--- 



EVENT NUMBER: 



TITLE OF BRIEF: 
TIME: 
LOCATION: 
BRIEFER: 
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* ♦ 

| ENTER USER DATA ! 

♦ + ♦ ♦ 

! EXERCISE TYPE: EVENT NUMBER: ! ! 

; + + ! 

! NAME OF COMMAND: 

• ■ 

i ■ 

1 NUMBER OF UNITS: _ ! 

■ i 

i > 

5 PINGER CHANNEL: ! 

i (IF SUBMARINE) 

i ■ 

! TRANSPONDER-EQUIPPED?: 

! (IF AIR OR SURFACE) 

+ + 

I TYPE OF WEAPON NUMBER PINGER ! 

i (MK) SCHEDULED CHANNEL ! 



+ ♦ 

+ + 

! ENTER TARGET DATA ! 

+ + 

! EXERCISE TYPE: EVENT NUMBER: ! 

l I 

I I 

! TARGET DESIGNATION: GEOMETRY CODE: 1 

I I 

I • 

l PROPER ACOUSTICS?: _ PINGER CHANNEL: ! 

I I 

I I 

I l 

I I 

! TARGET LAUNCH VEHICLE: ! 

I I 

i I 

+ + 

+ + 

! COMMENTS ! 

♦ ♦ 

! COMMENTS ! 
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B. RESULTS APPLICATION 



♦ + 

! EXERCISE SUMMARY i 

+ ♦ 

! EXERCISE EVENT EXERCISE DESCRIPTION | 



! OPAREA ! 

: COHEX VISIBILITY _ ! 

! FINEX SEA STATE 

+ — + 

! REASON CANCELED HOURS T I HE OF 

LOST CANCELLATION \ 



+ — + 

! LAUNCH/RECOVERY ASSETS ! 

I » 

I I 

! PLATFORM SIDE NUMBER USED ! 



4 4 



USER 


DATA 


EXERCISE 


COHHAND DESIGNATION 




SIDE NUHBER 


SHOWED FOR EXERCISE 




TRACK QUALITY 


SONOBOUY USAGE: LOFAR 






DIFAR 






DICAS 






VLAD 


— 




WEAPON TYPE 


NUHBER 


REASON 


SCHEDULED 


NOT DROPPED 
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ATTACK DATA 



+ + 

! EXERCISE COMMAND SIDE NUMBER i 

+ + 

; TOF START ATTACK RUN ! 

+ + + + 

! TAR6ET DATA \ SOLUTION DATA J FIRING UNIT DATA ! 

J I I I 

! COURSE _ : COURSE _ ! COURSE _ \ 

! BEARING _ ! BEARIN6 ! SPEED _ ! 

! RAN6E ! RANSE ! ALTITUDE ! 

! SPEED _ ! SPEED _ ! i 

! DEPTH | + + 

! ! DOPPLER _ ! 

! MANEUVER: j ! 



; course : 

: SPEED _ ! 

+ + 



ATTACK DATA 

i- + 

EXERCISE UNIT SIDE NUMBER TOF ! 

+ — - + 

! FIRIN6 DATA RESULTS ! 

I t 

! CONTACT TYPE ACQUIRED _ 1 

! ATTACK MODE ATTACK EVAL 1 

! SONAR SETTING PH _ | 

! DELIVERY MODE SPLASH BEARIN6 _ ! 

! SEARCH DEPTH SPLASH RAN6E ! 

+ — + 

ATTACK COMMENTS: 
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WEAPON DATA 



+ 1 

{EXERCISE UNIT SIDE NUMBER TOF ! 

* -♦ 

: HK NOD SERIAL \ 

! TRACK QUALITY TORPEDO PERFORMANCE \ 



WEAPON RECOVERED(Y,N) 

SEARCH TIME RECOVER VEHICLE 



! TIME TO RECOVER BRING BACK VEHICLE ! 

+ + 



TARGET DATA 



+ + 

! EXERCISE 

+ - - + 

I I 

! TARGET DESIGNATION MOD SERIAL NUMBER J 

I I 

I I 

! LAUNCH TIME TRACK QUALITY | 

I I 

I 1 

I PERFORMANCE GEOMETRY 

I I 

! SOUND LEVEL FREQUENCY BAND _ ! 

I 1 

! RECOVERED[Y,N) . RECOVERY VEHICLE ! 

I 1 

I I 

+ i 



LOST TARGETS AND N E A P 0 N S 



♦- + 

I EXERCISE MK MOD SERIAL NUMBER ! 

: TOF ! 

+- ........ .+ 



TIME OF LOSS 



LATITUDE 



LONGITUDE 



! IMPLOSION DEPTH ! 

I I 

I I 

i WATER DEPTH ! 

♦ + 
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UNCLASSIFIED COMMENTS 



f 



EXERCISE 

+ 



! COMMENTS 

I 

I 



l 

I 

4 

i 

i 



i 

i 

i 

\ 



CLASSIFIED COMMENTS 
+ - 

! EXERCISE 

♦ — - 

! COMMENTS 
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APPENDIX K 



SYSTEM USER MANUAL 



In troduc tion : 

This manual introduces and explains the operation of 
the two 0-Base applications. These applications are de- 
signed to minimize the effort required for data entry. They 
also provide the ability to modify, delete and query the 
database. The Schedule application stores the event data 
that make up the schedule, and provides an easy method for 
making changes to the event data as circumstances change or 
more information becomes available. The Results application 
stores information about what occurred during an event. This 
information can then be queried or used to produce various 
repor ts . 

About This Manual : 

This manual is designed to guide you to in using the 
system. It assumes that you have completed the SQL*FORMS 
Operator's Guide tutorial, and are familiar with the various 
terms used in that manual. If you are unfamiliar with the 
terms block, record, form and query, refer to the SQL*FORNS 
Operators' s Guide. 

This user manual contains two parts, Part I covers the 
Schedule application and Part II the Results application. 
Each part is divided into seven sections: 1) Introduction, 

2) Description of the form, 3) Add procedures, 4) Modify 
procedures, 5) Delete procedures, 6) Querying the database, 
and 7) Detailed description of each field. The most useful 
section will be the detailed field descriptions, because it 
describes how each field operates. This section should be 
kept handy as a reference even, for experienced operators. 

Conventions and General Operating Procedures: 

• When a function key is described in the manual, the 
Oracle name will be given first, followed by the 
IBM/MS-DOS keyboard name enclosed in < >. 

• When entering data into a field, a Next Field <Enter> 
moves the cursor to the next available field. 

• When entering a field, a short help message appears at 
the bottom of the screen. 



i i 3 



Starting the Applications ; 



To start the application, make sure that Oracle was 
started properly. Then, type either Schedule or Results 
followed by a carriage return <cr>. This will start the 
appropriate application. You will then be asked for your 
name and password. Enter your name and password followed by 
a carriage return <cr> . If you do not have or forget your 
password see your Database Admin is tra tor . 
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PART I 



SCHEDULE APPLICATION 



1 . I n t roduc t ion : 



This application stores each scheduled event into the 
database so that a schedule can be constructed. The proce- 
dure for entering data has been made as simple as possible. 
You type in the data you wish to enter and then press the 
Enter <cr> key. The most important information entered is 
the exercise type and the event number, since this informa- 
tion determines the event to which you are referring. Upon 
entering a new event the system will au toma t ic a 1 1 y give you 
an event number based on the year in which it is scheduled. 
Once the system knows what event to which you are referring, 
you may either add, modify, or delete information from that 
even t . 

2 . Form Description: 



The schedule contains six blocks: Exercise, Brief, 
Users, Weapon, Target, and Comments. These blocks are the 
basic subdivision used by SQL#FORMS. This grouping of 
information allows for quicker navigation. Using the Next 
Block <page down> and Previous Block <page up> any block may 
be accessed quickly. 

The exercise data block is the first block and contains 
three pages of data. The first page contains the exercise, 
event number and scheduled start and stop times along with 
other general event information. The second page contains 
tracking requ i remen ts , and message information, while the 
third contains information on recovery vehicles. 

The next block is the Brief block. It contains infor- 
mation on briefs associated with the event. This block is 
set up to allow multiple briefs to be entered for an event. 
Entering nothing into the block will move you directly to 
the User B1 ock . 

The User block contains information about the commands 
scheduled to use the range during this event. Many users 
can be involved in a single event. To view other users, the 
Next Record key <down arrow> can be used to scroll both the 
user and the weapons associated with it. Entering a blank 
in the command field will move you to the Target block, 
while next block will move you to the Weapon block. 

The Weapon block is on the same page as the User block. 
This arrangement allows the weapons data to be viewed with 
their respective user. This block allows you to view two 
weapons at a time and, as indicated above, Next Record <down 
arrow> and Previous Record <up arrow> can be use to scroll 
the records. 
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The Target block, located on page four, allows entry of 
data pertaining the target scheduled for an event. 

The last block is the Comments block which contains 
notes on the event. Upon completion of this block, all data 
entered is au toma t ic a 1 1 y stored into the database. 

3 . Add Procedures: 



This section describes how new data is entered into the 
system. This is a general description of the process and 
should be used in conjunction with the detailed field de- 
scriptions. Before starting to enter new data, you should 
have at hand all of the information you are going to enter, 
particularly the exercise, user, and target information. 



Step 1. Start at the top of the form ( If not at top of 
form, select Previous Block <page up> until you get a mes- 
sage saying "top of form" on the status line). Select 
Create Record <F9> , which sets up the form to enter a new 
record . 

Step 2. Enter your exercise type and the last two digits 
of the year in which the event will occur. This allows the 
system to calculate the proper event number. 



Step 3. Enter your data, field by field as described in 
the detailed field descriptions. 



Step 4. Once you are in the Brief Block enter your infor- 
mation regarding the first brief. After entering the brie- 
fer, the block will clear and the cursor repositions to the 
brief title field. You can enter another brief or, if fin- 
ished entering briefs, press return. You will now be at the 
top of the User block. Enter your user data. 

Step 5. After entering your user data, you are presented 
with the Weapon block. Enter the data for the first weapon. 
Following the pinger channel entry, the cursor will reposi- 
tion under the first weapon entered. Continue entering data 
for all weapons scheduled. Pressing return on an empty "Type 
of Weapon" field will return you to a blank User block. You 
have the option of entering another user or nothing. If you 
entered all your users then enter nothing and move to the 
target block . 

Step 6. Enter your target data. When finished you will 
move into the Comments block. Enter your comments, pressing 
return twice when finished. All data entered is stored and 
you are returned again to the first screen. 
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4 . Modi f v Procedures : 

Modifying an existing entry is s traight f orward . First, 
retrieve (see Querying the Database) the event to the 
screen, then change or add data as if you were entering data 
for the first time- The exception to this procedure is that 
you can not change exercise or event numbers- To enter a 
new brief or user you must either select Create Record<F9> 
or Next Field <enter> until a blank record appears on the 
screen- To add a weapon to an existing command go to the 
User block and select Next Record <down arrow> until the 
desired user name appears- Then use Next Field <enter> to 
move to an blank weapon line and enter the information. To 
add an additional target, go to the Target block and select 
Next Record <enter> or Create Record <F9> , and enter the 
information. To add additional comments just add them to 
the previous comments. Note however, blank lines are not 
allowed. If you want to separate comments, use some key- 
board symbol, such as or ,, = " on a line to sep- 

arate them. 

5 . Delete Procedures: 



Delete works on many levels: you can delete an entire 

event or any of its various objects (Brief, Users, etc-). 

To delete an entire event you must first be in the 
Exercise block then retrieve the desired record as described 
in the next section. Once the desired event is displayed 
select Delete Record <shift F5> . This will delete the 

entire event including any Briefs, Users, Targets and Com- 
ments associated with the event. 

Any record in the other blocks can be deleted in the 



same manner. First, display 
select delete record. When 
associated with that User are 
block selecting delete record 
time . 



the record tc be deleted, then 
deleting a User the Weapons 
also deleted. In the comments 
will only delete one line at a 



6 . Query Database : 

The ability to query the database in this application 
is limited. In all blocks except the Exercise block que- 
ries are constrained by the exercise type and event number 
displayed. For example, if you are in the Brief block, the 
only records retrieved in response to a query will be those 
associated with the exercise type and event number displayed 
at the top of the block. Even with this limitation many 
useful queries may be done. 

The easiest query to perform is a general query. This 
retrieves all records. To do this you must be in the Exer- 
cise block. Then select Execute Query <F2> , which will 
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retrieve all events. They may then be viewed sequentially by 
selecting Next Record <down arrow>. 

The other type of query is a selected query, through 
which you retrieve records that satisfy certain selection 
criteria (For example, exercise type = "Torpex" ) . This is 
also done from the Exercise block. Select Enter Query <F1> 
and enter the selection criteria into the fields that you 
wish to query, then select Execute Query <F2> . One example 
would be to query all data relevant to a particular exer — 
cise. The procedure would be: (1) Enter Query <F1>, (2) 

enter the exercise type and the event number, and (3) select 
Execute Query <F2> . This would either retrieve the record 
or say no record selected, in which case you can enter 
another query. More complex queries are possible and are 
described in the SQLfcFORMS Operator's guide chapter 11. 

7 . Detailed Field Descriptions : 



This section provides a quick reference on each field 
and shows the screen layouts. 



Exerciie Block (Page 1): 



+ - 



INPUT NEW EVENT DATA 

+ 4 - 

1 EXERCISE TYPE! EVENT NUMBER! 

! EXERCISE DESCRIPTION! 



t — — 



♦ 



+ 



EXERCISE TIMES! 



SCHEDULED START! 
MOCS MAN-UP! 



SCHEDULED FINISH! 
MOCS SHUT-DOWN; 



EXERCISE PERSONNEL! 



PROJECT ENGINEER! 
OPERATION CONTROL! 
OPERATION ANALYST* 
SAFETY OFFICER: 



OPERATIONAL AREA ASSIGNED! 



EXCLUSIVE USE?! 



Fields : 



Exercise Type: 

List Values 
cises. This 



Enter the type of exercise to be scheduled. 

<F4> can be used to review standard exer- 
field is mandatory. 
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Event Number: In this field the only input allowed are the 

last two digits of the year in which the exercise will 
occur. Once this data is entered, the proper event 
number is automatically generated. This field is 
manda tory . 

Exercise Description: This field is au toma tica 1 1 y filled 

in based on the exercise, but may be changed to fit the 
actual exercise needs. 

Schedule Start: Enter the schedule start time in standard 

military date-time group format DDHHNNZ MONYY . Where 
DD is the day of the month, HHMM is military time, Z is 
the time zone (San Diego is U time), NON is the three 
letter abbreviation for the month, and YY is the last 
two digits of the year. Entering the wrong format will 
cause an error message to be displayed. To get more 
information on the error Display Error <shift-F10>. 



Scheduled Finish: This is the scheduled stop time for the 

event. It has to be in the standard format described 
above . 

NOCS Nan-up: This is the time that the NOCS should be 

manned up. The default is one hour before the sched- 
uled start time. This must be in standard format 

DDHHNNZ NONYY. 

NOCS shut-down: This is the time scheduled to shut down 

the NOCS. The default is one hour after scheduled 
finish. This is also entered in standard format. 

Exercise Personnel: These four fields are used to indicate 

the personnel scheduled for the event. You may enter 
either initials or up to 10 characters of their name. 



Operational Area: 
even t . 



The scheduled operational area of the 



Exclusive 

area 



Use: This Y/N field indicates 

is reserved exclusively for the 



if the operational 
exerc i se . 
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Exercise Block (Page 2): 



MISCELLANEOUS EVENT DATA 



! EXERCISE TYPE* EVENT NUMBER* 

♦ 

TRACKING TYPE* 



EVENT MESSAGES* 

6REEN REQUIRED?: _ GREEN SENT?: 

SUBMARINE RELAXATION NESSA6E REQUIRED?* 



AIR SPACE RESTRICTIONS: 
COMMUNICATIONS: 



Fields : 

Exercise, Event: These fields are are replicated from the 

first page and cannot be entered. 

Tracking Type: The type of tracking required for the 

event. Enter E for EATS tracking, I for in-water or 
B for both. 

Green Required: Is a rainform green 

Enter either Y or N. If one is not 
lowing Green Sent field is skipped. 

Green Sent: This field defaults to N and should be changed 

to Y when the required rainform green message is sent. 

Submarine Relaxation: This is used to indicate if a sub- 

marine relaxation message is required, either Y or N. 

Air Space Restrictions: This field states the altitude 

limits for aircraft involved in the event. The heights 
are in hundreds of feet with the low altitude first. 
For instance if the allowable altitude was 0 to 5000 ft 
the entry would be 00-50. 

Communications : This is the primary frequency for com- 

munication during the exercise, usually UHF . 



message required, 
required, the fol- 
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Exercise Block (Page 3)i 



! EVENT SUPPORT VEHICLES ! 

+--+ +--+ 

i ! EXERCISE TYPE: EVENT NUMBER: ! 

! + - + ; 

I i 

! TARGET SUPPORT VEHICLES: ! 



PRIMARY TAR6ET RECOVERY: 

SECONDARY TARGET RECOVERY: 

WEAPON SUPPORT VEHICLES: 



PRIMARY WEAPON RECOVERY: 
SECONDARY WEAPON RECOVERY: 
WEAPON HAULBACK: 



Fields: 

Exercise, Event: These fields are replicated from the first 

page and cannot be entered. 

Recovery Vehicles: These five fields are for listing the 

primary and secondary vehicles scheduled to provide 
support to the event. In each field enter the name of 
the command that will provide that support. List 
Values <F4> may be used to list commonly used commands. 
After weapon haulback is entered you will move to the 
Brief Block. 
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Brief Block (Page 4)i 



+ + 

: INPUT EXERCISE BRIEF DATA ! 



! EXERCISE TYPE) 


EVENT NUMBER) 











! TITLE OF BRIEF) 1 

I I 

! TINE) ! 

I I 

! LOCATION: | 

I I 

! BRIEFER) ! 

I I 

I I 

4 4 



Fields: 



Exercise, Event: These fields are replicated from the first 

page and cannot be entered. 



Title of Brief: Enter the title of the brief. Leaving 

this field blank will move y«w directly t R thp User 

Block. 



Time: Enter the scheduled time of the brief in standard 

date-time group format DDHHMMZ MONYY . See Exercise 

block scheduled start field for details of the date- 
time format. 



Location: Enter the location where the brief will be held. 

Briefer: Enter the Name of the person who will give the 

brief. After entering this field you will move back to 
the Title of Brief field, allowing you to enter another 
brief . 
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Uitr Block (Pigi 3)t 



! ENTER USER DATA 1 

+ + + + 

! 1 EXERCISE TYPE i EVENT NUHBERi ! ! 

1 + + 1 

1 NAME OF COMMAND t ! 

I i 

! NUMBER OF UN ITS t _ ! 

I I 

! RINSER CHANNEL: i 

! (IF SUBMARINE) ! 



TRANSPONDER-EQUIPPED? i 
(IF AIR OR SURFACE) 



TYPE OF WEAPON 


NUMBER 


PIN6ER 


(UK) 


SCHEDULED 


CHANNEL 




- 


— 



Fields: 



Exercise, Event: These fields are replicated from the 

first page and cannot be entered. 

Name of Command : Enter the name of the command, using 

command designations ( ie VP-44, SSN-680). If you leave 

this field blank the system assumes that you have 
entered all the commands for this event and moves you 
to the Target Block. 

Number of Units: This field is entered only if the command 

is an aircraft squadron. Enter the number of aircraft 
from this command that will participate in the event. 

Pinger Channel: This field is entered only if the command 

is a submarine. Enter the pinger channel to be in- 
stalled on the sub. From this field you move directly 
to the Weapon block on the same page. 

Transponder Equipped: This applies only to ships and 

aircraft. Enter the type of transponder to be in- 
stalled. After entering this field you move to the 
Weapon block on the same page. 
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Weapon Block: 



Fields: 



Type of Weapon: Enter the type of weapon scheduled for this 
command. Leaving this field blank will move you back 
to the user block allowing you to enter another 
command . 

Number Scheduled: Enter the number of weapons of this type 

sc hedu 1 ed . 

Pinger channel: Enter the pinger channels to be used by 

the weapons. If four weapons are scheduled, two with A 
pingers and two with B pingers, then enter 2A2B. After 
entering this field you will move back to Type of 
Weapon field allowing another type of weapon to be 
scheduled for this user. 



Tirgit Block (Pigi 6)1 



ENTER TARGET DATA 


EXERCISE TYPE: 


EVENT NUMBER: 






TARGET DESIGNATION: 


GEOMETRY CODE: 


PROPER ACOUSTICS?: _ 


PINGER CHANNEL: 


TARGET LAUNCH VEHICLE: 





Fields: 



Exercise, Event: These fields are replicated from page 1. 

Target Designation: This field contains the designation of 

the target. If the target is a ship or submarine the 
designation is just its command. If it is a mechanical 
target, enter its MK number. If the target is a ship 
or submarine, the remainder if the block is not ap- 

plicable, and you will move directly to the Comment 
block. 



Enter the geometry programmed into the 



Geometry code: 
target . 
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Proper Acoustics: Verify that the target has the proper 

acoustics, either V or N. 

Pinger channel: Enter the pinger channel to be used by the 

target . 

Target Launch Vehicle: Enter the command that will launch 

the target. After entering this field you will move to 
the Comments Block. 



Coninti Block (Pigi 7)t 



+ ♦ 

! COMMENTS ! 

+ + 

! COMMENTS | 



Fields: 



Comments: This 

pertaining to 
necessary . T o 
To move to the 
will then be 
block . 



field all ows 
the event, 
move to the 
Next Block 
at the top 



you to enter any comments 
You may use as many lines as 
Next Line select enter <cr>. 
select enter <cr> twice. You 
of the form in the Exercise 
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PART II RESULTS 



1 . In troduc tion : 



This application stores the data recorded during the 
event so that it can be reviewed and analyzed later. It 
also allows the user to query and generate reports on the 
stored data. As with the schedule application, it was 
designed to minimize the effort required for data entry. 
The same <enter> key will move you through the entire form. 
Before an event can be entered it must first exist in the 
Schedule application, ensuring that data can pass between 
the two applications. This application is much larger that 
Schedule and has more blocks, but should be no more complex 
to operate. 

2 . Form Description: 

The form contains 13 blocks on nine screen pages. The 
blocks are Result, Cancel, Launch/Recovery, User, Scheduled 
Weapons, Attack, Attack Comments, Weapon, Target, Unclas- 
sified Comments, Classified Comments, and Lost. 

The Result block is the first and master block. It 
contains the exercise type and event number, along with the 
oparea, comex , finex and weather information. This is the 
only block from which you can query multiple events. 

The next two blocks, Canceled and Launch/Recovery, are 
also on page one. Canceled is for entering reasons why part 
or all of an event was canceled. The Launch and Recovery 
block records whether or not a scheduled recovery vehicle 
was used. Both of these blocks are multi-record blocks, 
showing up to three c ance 1 1 a tions and four recovery vehicles 
at once. As in all other multi-record blocks entering 
nothing moves you to the next block. 

On page two are the User and Scheduled Weapon blocks. 
The User block records the actual platform that was on the 
range. From this block, you move into the Scheduled Weapon 
block which is a multi-record block. 

The Attack block on page three is one of the most 
important because it records all the attack data for the 
command in the User block. This block covers two pages and 
leads directly into Attack Comments. These comments go 
directly with the attack described above it. 

Moving to page five, we start to see the complex navi- 
gation controls of this application. The path so far has 
moved directly through the form. Attacks can involve actual 
or simulated weapons. If the attack was simulated you will 
return to the Attack block, allowing you to enter another 
attack. Otherwise you may enter Weapon data, which, upon 
completion, will also bring you back to the Attack block. 
If there are no more attacks conducted by this platform you 
will return to the User block were another platform may be 
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entered. If all users for an event have been entered you 
move on to the Target block. 

The Target block cavers information on the target. 
Once this is entered you will move to the event Comment 
blocks. The first is for general comments on the exercise, 
while the second is for any comments that are classified. 

The last block is the Lost block for recording informa- 
tion on lost weapons or targets. The only way to get to 
this block is for a loss to be recorded in either the Weapon 
or Target blocks. Upon leaving this block, you will either 
return to the Attack block (if the item lost was a weapon), 
or to the Unclassified Comments block (if the item lost was 
a target ) . 

3 . Add Procedures : 

This section explains how new data is entered into the 
system. This is a general description of the process and 
should be used in conjunction with the detailed field de- 
scriptions provided below. Before entering new data you 
should have the exercise summary at hand. 

Step 1. Start at the top of the form (If not at top of 
form, select Previous Block <page up> until you get a mes- 
sage saying “top of form" on the status line). Select 
Create Record <F9> , which sets up the form to enter a new 
record . 

Step 2. Enter your exercise type. Next enter the event 
number. Once these items are entered you can select Dupli- 
cate Record <F7> , which will copy pertinent data from the 
schedule into the Results form (this may take 10 to 15 
seconds to complete). You can now edit or accept the values 
copied over from the schedule. 

Step 3. Continue to enter data until you get to the Can- 
celed block. Here, if no cancellation occurred , leave blank 
and move to Launch and Recovery assets. 

Step 4. You need to edit the Launch and Recovery values 
copied from the schedule. If the platform was not avail- 
able, delete it using Delete Record <shift-F5>. The side 
numbers have to be changed to match the actual side number. 
When finished, select Next Field <enter> until you move to 
the nex t block. 

Step 5. You are now in the User block. Enter your user 
data, moving automatically into Scheduled Weapons. When you 
finish entering the scheduled weapons you will move to the 
Attack block . 
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Step 6. Enter your attack data and attack comments. Once 
this is complete you will move to the Weapon block. If no 
weapon was fired leave blank, otherwise enter the informa- 
tion (if a weapon was lost see step 8). In either case you 
will return to a blank Attack block. You may enter another 
attack for the displayed platform, or leave blank. Leaving 
the field blank returns you to the User block. Again you 
can enter another user or leave blank. Leaving the field 
blank takes you to the Target block. 

Step 7. In Target block enter the appropriate data (if the 
target was lost see step 8 ) . When target entry is complete 
you will move through the Comment blocks and then back to 
the first page of the application to enter additional exer — 
cise results. 

Step 8. If you indicated that a weapon or target is not 
recovered you will move au toma t ic a 1 1 y to the Lost block. 
Here you enter data about the loss. Upon completing the 
block you will exit to the Attack block (if the item lost 
was a weapon), or to the Unclassified Comments block (if the 
item lost was a target). 

After entering an event the data will be saved and you will 
return to the top of the form. You can repeat the process 
and enter another event or perform another operation. 



4 ■ Modify Procedures ; 

Modifying an existing entry is st raig ht f orward . First, 
retrieve (see Querying the Database) the event to the 
screen, then change or add data as if you were entering data 
for the first time. The exception to this procedure is that 
you may not change exercise type or event number. To enter 
a new User or Attack you must select Create Record <F9> in 
that block. To add a Cancellation or a Support vehicle, you 
must go to the desired block and select Next Record <down 
arrow) until a blank line appears, then enter the informa- 
tion . To add an additional target, go to the Target block 
and select Next Record <down arrow) or Create Record <F9>, 
then enter the information. To add additional Comments, 
just add then to the previous comments. Note, however, that 
blank lines are not allowed. If you want to separate com- 
ments use keyboard symbols such as " * “ , or “=“ to 
separate them. 

5 . Delete Procedures : 

Delete works on many levels: you can delete an entire 
event or any of its associated objects. You can only delete 
an entire event, however, if it has no associated Users or 
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Targets. This prevents inadvertent deletion of records. 
This same procedure applies to User. No user can be deleted 
if an Attack is associated with it. 

To delete an entire event perform the following steps: 
i) Delete all Attacks associated with the Users of the event 
(this au toma t ica 1 1 y deletes all Attack Comments); (2) Delete 
all Users of the event (this au toma t ic a 1 1 y deletes all 
Weapons assigned to the Users); (3) Delete Target(s) as- 
sociated with the event; and (4) Enter the Result block and 
select Delete Record <shift-F5>, which au toma tica 1 1 y deletes 
all Comments, Cance 1 1 a t ions and Support, along with the 
even t i tse 1 f . 

If there are no Users and Targets associated with an 
event to be deleted, go directly to step (4). 

All other blocks can be deleted individually as shown 
in the SQL#FORMS manual. 



6 . Query Database : 



The ability to query the database in this application 
is limited. In all blocks except the Result block, queries 
are constrained by the exercise type and event number dis- 
played. For example, if you execute a query in the Attack 
block, the response to the query will pertain to the par- 
ticular exercise type and event number displayed at the top 
of the Attack block. Even with this limitation, full queries 
may be performed. 

The easiest query to perform is a general query. This 
retrieves all records. To perform this query, enter the 
Result block and select Execute Query <F2> . This will 
retrieve all events which may then be viewed sequentially by 
selecting Next Record (down arrow). 

The other type of query is a selected query, through 
which you retrieve records that satisfy selected criteria 
(For example, exercise type = "Torpex"). This query is also 
executed from the Result block. The general query procedure 
is as follows: i) Select Enter Query <F1>; 2) Enter selec- 
tion criteria into the fields you wish to query; and 3) 
Select Execute Query <F2> . One example would be to find a 
particular exercise. After entering the Result block, the 
procedure would be: 1) Enter Query <F1>; 2) Enter the exer- 
cise type and event number; and 3) Select Execute Query 
<F2> . This will either retrieve the desired record or say 
"no record selected", in which case, you can enter another 
query. More complex queries are possible and are described 
in the SQL*FORMS Operator's guide chapter 11. 
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Result Block (Pige l)t 



+ + 

! E X E R C I S E S U H N A R V ! 

+ ♦ 

! EXERCISE EVENT EXERCISE DESCRIPTION ! 



! OPAREA ! 

I COHEX VISIBILITY _ ! 

! FINEX SEA STATE _ ! 

+ + 

! REASON CANCELED HOURS TIHE OF 

! LOST CANCELLATION ! 



LOST CANCELLATION 




LAUNCH/RECOVERY ASSETS 



PLATFORM SIDE NUMBER USED 




Special Keys; 

Duplicate Record <F7>: This key copies information from 

the Schedule to the Results application. After enter- 
ing the exercise type and event number, press this key 
to copy the oparea, scheduled comex and finex into the 
appropriate fields. It will also list all the recovery 
vehicles in the launch/recovery block. 



F lelds : 

Exercise: Enter the type of exercise. (Standard exercise 

types are available by selecting List of Values <F4>) 
This field is mandatory, and must exist in the 
sc hedu 1 e . 

Event: Enter the event number. This field is also man- 

datory, and the event must be in the schedule. 

Exercise Description: This field is automatically filled 

in and cannot be edited. 

Oparea: Enter the operational area in which the event took 

place. 
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Comex : Enter the date and time of the comex in standard 
military date time group format DDHHMMZ MONYY . Where DD is 
the day of the month, HHMM is military time, Z is the time 
zone (San Diego is time zone U), MON is the three letter 
month abbreviation and YY is the last two digits of the 
year- If this format is not used an error message will 
appear; select Display Error <shift-F10> to get a 
description of the error. 



Finex: Enter the finex 

format as above. 



time of the event in the same 



Visibility: Enter the visibility in nautical miles. 

99 to indicate unlimited visibility. 



En ter 



Sea 



state: 

state. 



Enter the single digit representing the sea 



Canceled Block: 

Fields: 

Reason Canceled: This is the reason for which part or all 

of the event was canceled. There are six valid en- 
tries: asset avai 1 abi 1 i ty , fouled range, instrumenta- 

tion, weather, no air tracks, and no show. These 
values are available using List of Values <F4>. Making 
no entry moves the cursor to the Launch/Recovery Block. 

Hours lost: This field records the length of the cancella- 

tion period. This data is recorded in hours and tenths 
of hours. 

Time of Cance 1 1 at ion : Enter the time at which the cancel- 

lation started. The format is the standard date-time 
group format of DDHHMMZ MONYY. See comex in the result 
block for more details. Once this is entered you will 
move to enter the next reason canceled. 



Launch/Recovery Block : 
Fields: 



Platform: Enter the command name of the support vehicle. 

If Duplicate Record was selected in the Result block 
the command name will be filled in from the schedule. 
If the schedule information was incorrect, select 
Delete Record <shift-F5> to delete the line. If this 
field is left blank you will move to the User Block. 



131 



Side number: Enter the side number of the vehicle. The 

values copied from the schedule have the letters A, B, 
C, and D. Insert the correct side number. 

Used: A Y/N entry indicating whether or not the vehicle 

was actually used to support the event. If it stayed in 
port or on the ground the answer is N. If the vehicle 
was broken or not available then it should not be 
listed. After entering this field you will move to the 
next platform in the list. 



User Block (Pige 2): 



USER DATA 



+ + 

! EXERCISE ! 

i + 



COMMAND DESI6NATI0N SIDE NUMBER 

SHOWED FOR EXERCISE _ TRACK QUALITY 

S0N0BU0Y USAGE i LOFAR _ 

DIFAR _ 

DICAS _ 

VLAD 



WEAPON TYPE NUMBER REASON 

SCHEDULED NOT DROPPED 



Fie Ids : 

Exercise: This field is replicated from the exercise type 

and event number fields of the Result block and cannot 
be entered . 



Command Designation: The 

range. The name is the 
the command ( ie VP-44 
include the hyphen. If 
system assumes you have 
volved in the event and 



name of the command using the 
standard Navy designation for 
or SSN-680). For consistency 
this field is left blank, the 
entered all the commands in- 
you move to the Target Block. 
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Side number: This field is only entered if the command was 

an aircraft squadron. Enter the side number of the 
actual aircraft that used the range. If a squadron was 
scheduled for two aircraft and one did not show enter a 
NS for no show. 

Showed for exercise: A Y/N entry indicating whether or not 

a scheduled user showed up for the event. 

Track quality: Enter the quality of the track observed by 

the range, from 0 (no track ) to 100 (a perfect track). 

After entering this field aircraft move to the sonobuoy 
field; all others go directly to Scheduled Weapons. 

Sonobuoy Usage: These four fields record how many buoys an 

aircraft uses. Enter the number of buoys used for each 
type. When exiting the last field, you will move to 
the Weapon block. 



Weapon Block: 
Fields: 



Weapon type: Enter the 

MK-46 or MK-48 . The 
and copy the number 
field. If this field 
the Attack block. 



type of weapon scheduled, either 
system will search the Schedule 
scheduled into the appropriate 
is left blank, you will move to 



Number scheduled: This field records how may weapons were 

originally scheduled. The total number of weapon type 
scheduled for a command is copied into this field. For 
aircraft squadrons, this number needs to be verified 
because the weapons may have been divided equally among 
all pi atf orms . 

Reason Not Dropped: A code indicating why all scheduled 

weapons were not dropped. The codes are: A) platform 

problems, B) torpedo problems, C) weather, D) inade- 
quate recovery assets, E) time constraints, F) fouled 
range, G) inadequate TMA, H) pinger problem, and I) 
other. After entering this data you will be able to 
enter the next weapon scheduled for this platform. 
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Attack Block (P»ge 3) i 



ATTACK DATA 



+ + 

! EXERCISE COMMAND SIDE NUMBER ! 

* + 

TOF START ATTACK RUN 

♦ * * * 

1 TAR6ET DATA i SOLUTION DATA ! FIRING UNIT DATA \ 

III I 

! COURSE _ ! COURSE _ ! COURSE _ ! 

! BEARING _ ! BEARING _ ! SPEED _ ! 

! RANGE 1 RANGE 1 ALTITUDE ! 

! SPEED _ 1 SPEED _ | | 

! DEPTH ! ♦ ♦ 

! | DOPPLER _ ! 

I MANEUVER* 1 j 

! TIME ♦ + 

! COURSE _ | 

! SPEED ! 



f + 



Fields: 

Exercise: Replication of exercise type and event number. 

Command: The command that conducted the attack. 

Side number: The side number of the platform that per- 

formed the attack (if applicable). 

TOF: Time of Fire. The time that the weapon was launched. 

This identifies the attack. The time must be entered 
in standard military date-time group format DDHHMMZ - 
MONYY . See Result block comex for more information on 
date-time format. 

Start Attack Run: Enter the time at which the platform 

starts searching for the target. This also has to be 
entered in standard date-time group format DDHHMM MON- 
YY. 

Target Course: Enter the course of the target at TOF 

[recorded in degrees true (0-359)]. 

Target Bearing: Enter the true bearing from the platform 

to the target at TOF (0-359). 

Target Range: Enter range from platform to target at TOF 

in yards. 
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Target Speed: Enter the speed of target at TOF in kts. 

Target Depth: Enter the depth of the target at TOF in 

feet. 

Maneuver time: The time in minutes after TOF at which the 

target maneuvered. The time is recorded in minutes and 
tenths of a minute. Enter 0 if no maneuver after TOF. 
Enter 0.1 if maneuver occurred at TOF. If 0 is entered 
the maneuver course and speed are skipped. 

Maneuver course: The new course after the maneuver [recor- 

ded in degrees true (0-359)]. 



Maneuver speed : 

the maneuver 

Solution Course: 
degrees true 

Solution Bearing: 

Solution Range: 

Solution Speed: 



The new speed of the target in kts after 

The firing solution course [measured in 
(0-359) ] . 

The firing solution bearing (0-359). 

The firing solution range in yards. 

The firing solution speed in kts. 



Doppler: A code entered to describe the amount of target 

doppler the firing craft was reading. The codes are: 
1) doppler > +5 kts, 2) doppler between +2.5 and +5 
kts, 3) doppler between -2.5 and +2.5 kts, 4) doppler 
between -2.5 and -5 kts, 5) doppler < -5kts. 



Firing Unit Course: Course of platform at TOF [measured in 

degrees true]. 

Firing Unit Speed: Speed of platform at TOF. 



Firing unit Altitude: 
field is skipped 
to the next page 
t ion . 



Altitude of aircraft at TOF. This 
for ships. After entry you will move 
and continue entering attack informa- 
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Attack Block (Page 4)s 



ATTACK DATA 
UNIT SIDE NUMBER 



EXERCISE 



TOF 



FIRING DATA 



RESULTS 



CONTACT TYPE 
ATTACK MODE 
SONAR SETTING 
DELIVERY MODE 
SEARCH DEPTH 



ACQUIRED 
ATTACK EVAL 
PH 

SPLASH BEARING 
SPLASH RANGE 



ATTACK COMMENTS? 



Fie Ids : 

Exercise, Unit, side number, TOF: These fields are not 

entered; replicating earlier recorded data. 

Contact Type: Enter the sensors used to develop the firing 

solution. There are 13 legal values which can be 

viewed using List Values <F4>. 

Attack Mode: Enter how the torpedo was programmed to 

perform its attack (either circle or snake). 

Sonar Setting: Enter the type of sonar the torpedo used. 

There are four settings available and may be viewed 
using List Values <F4> . 

Deliver Mode: Enter how the weapon was launched. There are 

six different delivery modes which may be viewed using 
List Values <F4>. 

Search Depth: The depth at which the weapon starts its 

search , in feet . 

Acquired: How many times did the weapon acquire the tar- 

get. If it did not acquire enter 0, If it acquired the 
target more than nine times enter 9. 

Attack Eval: Evaluation of the attack. There are five 

legal values, HIT, MISS, PROB HIT, PR0B,MISS, UNKNOWN. 
These values are also available using List Values <F4> . 
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If the platform that launched the attack was not an 
aircraft you will automatically skip to Attack Comments 
Block. 

PH: Enter the decimal value of the Probability of Hit 

(0.00 to i .00) . 

Splash Bearing: The relative bearing from the target to 

the splash point (0-359). 

Splash Range: Range from target to splash point, in yards. 

After entering this field you will move to Attack 
Comments Block. 



Attack Comments Block: 
Fields: 



Comments: This field allows you to enter comments that 

pertain to the specific attack shown at the top of the 
screen. Select return at the end of each line to move 
to the next line. Selecting return twice will move you 
to the Weapon Block. 



Wtipon Block (Page 5) i 



WEAPON DATA 

+ - ♦ 

! EXERCISE UNIT SIDE NUMBER _ TOF ! 

+ - + 

HK MOD SERIAL 

TRACK QUALITY _ TORPEDO PERFORMANCE 

WEAPON RECOVERED(Y,N) 

SEARCH TIME RECOVER VEHICLE 

TIME TO RECOVER BRIN6 BACK VEHICLE 



Fields: 

Exercise, Unit, Side Number, TOF: These fields are not 

entered, but are replicated from earlier data. 
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MK : 



Enter the MK of the weapon, enter MK-48, MK-46 or any 
other weapon used. If no weapon was launched as in a 
simulated attack , leave blank and you will return to 
the attack block to enter another attack. 



MOD: 



Enter the mod of the weapon, 



Serial: Enter the serial number of the weapon (up to seven 

characters long). 

Track Quality: Enter the quality of the weapon track from 

0 to 100. 

Torpedo performance: Enter the performance of the weapon. 

There are six legal values which may be selected by 
using List of Values <F4> . 

Weapon Recovered: This field indicates if the weapon was 

recovered or not. If N is entered, you will move 

directly to the Lost block. If Y is entered, you will 
continue entering data in this block. 

Search Time: Enter into this field the number of seconds 

that the weapon was in the search mode. 

Recover vehicle: The vehicle that picked up the weapon 

(i.e., TWR-789 or HC-1 345). 

Time to Recover: Enter the length of time between when the 

weapon stopped running and when it was retrieved. 
Measured in minutes. 



Bring Back Vehicle: The vehicle that returned the weapon 

to San Diego. After entering this field you will move 
back to the attack block to allow entry of another 
attack by this platform. 
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Target Block (Page 6)i 



TARGET DATA 

♦ ♦ 



EXERCISE 


TARGET DESIGNATION 


MOD 


SERIAL NUMBER 


LAUNCH TIME 




TRACK QUALITY 


PERFORMANCE 




SEOMETRY 


SOUND LEVEL 




FREQUENCY BAND 


RECOVERED(Y.N) 




RECOVERY VEHICLE 



Fields: 

Exercise: This field is not entered, but replicates exer- 

cise type and event number. 

Target Designation: If the target is a ship or submarine, 

enter its command name. For a mechanical target enter 
the MK. If a ship or submarine is entered the remain- 
der of the block is not applicable, and you move to 
the Comments blocks. 

Mod: Enter the mod of the target. 

Serial Number: Enter the serial number of the target. 

Launch time: Indicate the target launch time in standard 

date-time group format DDFIFIMMZ MONYY . See the Comex 
field in the Results block for more information on the 
date-time format. 

Track quality: Enter the quality of the target track 

during the event (0 -100). 

Performance: Enter the target performance. There are six 

legal values which may be viewed by selecting List 
Values <F4> . 

Geometry: Enter the geometry that was used by the target. 

Sound Level: Enter the average sound level generated by 

the target (measured in DB ) . 
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Frequency Band: Enter the type of sound generated by the 

target- The two legal values are NB for narrow band 
and BB for broad band. 

Recovered: This is a Y/N field indicating if the target 

was recovered. If it was not recovered, you will move 
to the Lost block. 

Recovery Vehicle: The vehicle that recovered the target. 

After entering this field you will move to the Unclas- 
sified Comments block. 



Undaiftifiid Coaamti Block (Paga 7) i 

UNCLASSIFIED COMMENTS 

t * 

! EXERCISE ! 

+ + 

COMMENTS 



Fields: 

Comments: Enter general comments about the event. The 

comments may be as many lines as needed. Use <Enter> 
to move to the next line. Pressing <Enter> twice will 
move you to the Classified Comments block. 



Classified Comments Block (Page 0): 



This 

for 

move 



block is identical to Unclassified Comments but is 
classified comments. Selecting <Enter> twice will 
you back to the top of the form (Result block). 
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Lott Block (Page 9) i 



LOST TARGETS AND WEAPONS 



+ f 

! EXERCISE HK HOD SERIAL NUMBER 1 

! TOF ! 

+ + 



TINE OF LOSS 
LATITUDE 
LONGITUDE 
IMPLOSION DEPTH 
WATER DEPTH 



Special Keys: 

Previous Block <page up> : This will return you to the 

block from which you came (Weapon or Target). 

Next Block <page down>: This will save the data in the 

Lost block and move you back to Attack (if the item 
lost was a weapon), or to the Unclassified Comments 
block (if the item lost was a Target). 

Fields: 



Time of Loss: Enter the time that the loss occurred in 

standard date-time group format DDHHMMZ MONYY . This 
field also has special definition for the Previous 
Field <shift-tab> key. If you enter Previous Field 
<shift-tab> the system assumes that you made a mistake 
and deletes the loss and moves you to the block from 
where you came. If you leave the field blank, you will 
also return to the block from where you came. 

Latitude: Enter the latitude where the loss occurred. 

Longitude: Enter the Longitude where the loss occurred . 

Implosion depth: Enter the depth at which it imploded, in 

feet (if unknown, enter 0). 

Water Depth: Enter the depth of the water where the loss 

occurred (in feet). After entering this field you will 
either return to the Attack block or advance to the 
Unclassified Comments block. 
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APPENDIX L 



SAMPLE REPORTS 



A- Sample Brief Reports 



BRIEF REPORT 



TITLE 


DATE 


TIME 


LOCATION 


BRIEFER 


PRE 






AUD 


HE 


AID 






HERE 


ME 


PRE 






A122 


HE 


PRE 






A122 


ME 


POST 


12 NAR 


1900 


IS-300 


HE 



BRIEF REPORT 



TITLE 


DATE 


TIME 


LOCATION 


BRIEFER 


PRESAIL 


OB JUN 


1100 


AUD 


YOU 


PRE 






AUD 


ME 


AUD 






HERE 


ME 


PER-BRIEF 






AUD 


HIM 


PREBRIEF 


03 MAR 


1700 


AUD 


PJD 


POST-SAIL 






SHIP 


DR 


PRE 






A122 


ME 


POST 






1-322 


DR 


PRE 






A122 


HE 


POST 






AUD 


YOU 


THESIS 






HERE 


DJR 


POST 


12 MAR 


1900 


IS-300 


HE 
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B 



Sample Weekly Schedule 



WEEKLY SCHEDULE 

PERSONNEL TRACKING SUPPORT VEHICLES 



EXERCISE TITLE 


COMEX-FINEX 


OPAREA 


PE OC OA SO 


EATS I/M 


PRIT6T SECTST PRIMEP SECMEP 


MONDAY 13 HAR 89 
A612 89082 TORPEX 


131200-131700 


SOAR 


A /B /C /D 


X 


X 


TMR 


TMR 


HC-1 


HC-1 


A601 89001 TORPEX 


131900-132200 


AREA1 


/ / / 


X 


X 


T 


T 


H 


H 


TUESDAY 14 HAR 89 
A601 89002 TORPEX 


140700-141855 


AREA1 


A /B /C /D 


X 


X 


HC1 


HC-1 


TRM 


TMR 


A601 89004 TORPEX 


141300-081600 


AREA1 


/ / / 


X 


X 


H 




TC 


TBY 


WEDNESDAY 15 HAR 89 
A612 89083 TORPEX 


151400-141800 


SOAR 


FJ/HN/PD/DR 


X 


X 


HC-1 


TMR 


HC-1 


TMR 


THURSDAY 16 MAR 89 
A601 89005 TORPEX 


160730-161300 


CAST1 


NN/RD/TH/RT 


X 


X 


HC-1 


TMR 


HC-1 


TMR 


FRIDAY 17 MAR 89 
M000 89001 MAINTENANCE 


171230-171700 


SOAR 


M6/M / / 
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